Credit Tokenization

Access Prerequisites

• Permission (module): viewCredits (access to the screen and listings). Project configuration/write operations follow the creditConfigManage gate; mint/burn/deploy are sensitive on-chain actions.
• License/Feature: CREDIT_INVESTMENTS enabled in the tenant license (Vault).
• Menu container: TOKENIZATION → group Tokenized Credit

What it is / when to use

Credit Tokenization is where the credit operation becomes an on-chain asset. The screen brings together three areas:

• Token Projects — registers and deploys the contracts that represent the credit on the blockchain (ERC-20 for fungible positions, ERC-1155 for receivables/charges).
• Investor Positions — tracks how many units each investor has allocated, minted, and burned per deal, and allows minting tokens.
• On-chain Transactions — ledger of all blockchain transactions (mint, burn, deploy) with hash, block, and gas, with a link to the explorer.

Use this screen after the deal is approved and disbursed, to issue the tokens that provide on-chain backing to the investors' position and to the receivable.

Prerequisites

• Permission: viewCredits to view; writing depends on the configuration/credit action gate (dual permission — CPM enum + dynamic module in the DB).
• License/Feature: CREDIT_INVESTMENTS enabled.
• Dependencies: the corresponding deal must exist and be in the appropriate state; to mint an investor position a deployed token project is required (with contractAddress). The mint/deploy wallet must be configured for the chosen chain.

Tab 1 — Token Projects

Each project represents a contract to be deployed. Filters: Project Type, Standard, and Status.

Project fields

Field	What it is	Required?	System/backend effect
Project Type	INVESTOR_POSITION, RECEIVABLE_ASSET, CHARGE_ASSET, or POOL_ASSET	Yes	Stored in projectType; defines the token's role (investor position, receivable, charge, or pool).
Standard	ERC20 or ERC1155	Yes	Stored in standard. Determines which contract is deployed: ERC-20 (fungible, e.g. position) or ERC-1155 (multi-token, e.g. receivables).
Chain	Target network (Ethereum, Polygon, BSC, Avalanche, Arbitrum, Optimism)	Yes	Stored in chainId. Defines which network the deploy and mints occur on and which explorer is used in the links.
Token Name	Token name	No	Stored in tokenName.
Token Symbol	Token ticker	No	Stored in tokenSymbol.
Contract Address	On-chain address	No (filled in on deploy)	Stored in contractAddress. When already present, the project is considered deployed and the deploy will not run again.
Metadata URI	Metadata URI (e.g. IPFS)	No	Stored in metadataUri.
Whitelist required	Restricts transfers to whitelisted addresses	No (default Yes)	Stored in whitelistRequired. Compliance control: only authorized wallets can operate the token.
Transfer restricted	Blocks free transfers	No (default Yes)	Stored in transferRestricted. Token "locked" to the custodied circuit until released.
Pausable	Allows pausing the contract	No (default Yes)	Stored in pausable. Enables the emergency kill-switch on the contract.
Status	DRAFT, DEPLOYED, ACTIVE, PAUSED, ARCHIVED	Conditional (on edit)	Stored in status. On creation the initial status is DRAFT.

Actions on the Projects tab

• Create / Edit / View project: the form saves via createTokenProject / updateTokenProject. View opens in read-only mode.
• Deploy: enabled when the project does not yet have a contractAddress and is in DRAFT or ACTIVE. Triggers deployTokenProject, which deploys the ERC-20 or ERC-1155 contract on the chain, returning contractAddress, the deploy hash, and deployedAt. If the contract is already deployed, the system returns the existing address instead of redeploying.

Tab 2 — Investor Positions

Shows, per deal: deal number, investor, allocated / minted / burned units, status, and the mint hash (with a link to the explorer). Can be filtered by deal (route .../investor-positions/deal/:dealId).

Mint action

• Mint tokens: the operator enters a value (prompt); if greater than zero, triggers mintInvestorTokens(dealId, amount). The backend issues the tokens on-chain and records the transaction.

Tab 3 — On-chain Transactions

Read-only ledger of all blockchain transactions. Filters: Status, Transaction Type, Entity Type.

Column	What it shows	Data source
Transaction Hash	On-chain hash	txHash
Entity Type / ID	The entity the tx refers to	entityType / entityId
Transaction Type	Mint, burn, deploy, etc.	txType
Status	On-chain confirmation state	status
Block / Gas	Block number and gas consumed	blockNumber / gasUsed
Created at	Record date/time	createdAt
Action (view)	Opens the chain explorer at that hash	getExplorerUrl(txHash, chainId)

Business rules / cautions

Attention

• Deploy runs only once per project. If contractAddress already exists, the system returns the current address without redeploying — there is no "redeploy" button. To get a new contract, create a new project.
• Compliance flags matter. whitelistRequired, transferRestricted, and pausable define the behavior of the deployed contract. Deploying with these flags set incorrectly means a contract with an unintended transfer rule — review before deploying.
• Chain defines the explorer and the mint wallet. Changing the chain switches which network everything is issued to; the mint/deploy wallet must exist for that chain, or the operation fails.

Irreversible (on-chain)

• Deploy, mint, and burn are on-chain operations. Once confirmed, there is no rollback: the contract remains deployed, the minted/burned tokens remain on the blockchain. Treat each action as final and verify values, deal, and chain before confirming.
• Mint/burn/deploy are sensitive actions and may require step-up (password + MFA re-auth, header X-Step-Up-Token, 5-min window) depending on the environment.

• Financial values: unit quantities (allocated/minted/burned) and the value entered on mint are treated as BigNumber — check the token's decimal places before minting.
• Idempotency: mint, burn, and deploy are protected by idempotencyKey — a transaction already recorded with the same key is not re-executed (the system reuses the existing one). Reprocessing after a crash is safe; an "already processed" response must be read as success, not an error.

Examples

Scenario 1 — Position stablecoin with exchange lock (restricted ERC-20)

Objective: tokenize the fungible position of an investor pool in BRL, without allowing free transfers outside the custodied circuit.

1. Tab Token Projects → Create.
2. Type: INVESTOR_POSITION. Standard: ERC20. Chain: Polygon.
3. Name/Symbol: "Pool Crédito BRL" / "pCRD".
4. Whitelist required: Yes. Transfer restricted: Yes. Pausable: Yes.
5. Save → project created in DRAFT.
6. Click Deploy → ERC-20 contract deployed, contractAddress filled in, status changes to DEPLOYED.
7. On the Investor Positions tab, Mint the units corresponding to each investor's position.

Result: fungible token transferable only between authorized wallets (compliance lock), with the possibility of an emergency pause.

Scenario 2 — Import an existing contract via address

Objective: register an already-deployed contract in the system (without redeploying).

1. Tab Token Projects → Create.
2. Set Type, Standard, and Chain consistent with the actual contract.
3. In the Contract Address field, paste the existing on-chain address.
4. Save.

Result: since the project already has a contractAddress, the Deploy button is not available (the system considers it deployed) and mints use the provided contract. Ensures the operation points to the correct contract without generating a new one.

Scenario 3 — Receivable as a multi-token asset (ERC-1155)

Objective: tokenize a batch of receivables as distinct assets under a single contract.

1. Tab Token Projects → Create.
2. Type: RECEIVABLE_ASSET. Standard: ERC1155. Chain: Polygon.
3. Metadata URI: point to the receivables JSON/IPFS.
4. Save → Deploy.

Result: ERC-1155 contract deployed, capable of representing multiple receivables (distinct IDs) under the same contract, with metadata per receivable.

Related screens

• Credit Guide — the tokenization phase in the full flow.
• Credit Policies
• Waterfall Templates
• Tokenized Credit (group index)