Template Catalog

Templates are pre-certified, ready-to-configure smart contracts that cover the most common use cases. Instead of developing from scratch, you can choose a template, configure it with your parameters, and deploy it quickly.

What is a Template

A template is a smart contract that is:

• Pre-certified: It has already passed the compliance process.
• Tested: Full tests and security analysis.
• Documented: Clear use cases and examples.
• Deployable: You only configure parameters and deploy.
• Maintained: ISBE updates and improves the templates.

Template vs Custom Development

Aspect	Template	Custom
Development	Configuration only	You develop your logic
Certification	Automatic	Full process
Flexibility	Limited to the standard	Total
Maintenance	Handled by ISBE	Your responsibility

When to Use a Template

Use a template if:

• Your use case fits into one of the available templates.
• You don't need specific business logic beyond the template.
• You prefer using proven and certified solutions.

When to Develop Custom

Develop custom if:

• You need specific functionality that does not exist.
• Your business logic is unique.
• You require particular validation rules.

See Custom Contract Development for more information.

---

Which template do I need?

Is your asset fungible (all tokens have the same value) or unique (each token is different)?

• Fungible and without financial regulation: ERC20
• Fungible and regulated (security, fund, bond): ERC3643
• Unique (certificate, credential, physical asset): ERC721

Do you need to record events or states of an asset over time?

• AssetEventTracker (lifecycle traceability)

Do you need to prove that a document or data existed at a specific time?

• HashTimestamp (timestamping, digital notarization)

---

ERC20: Fungible Tokens

ERC20 tokens are interchangeable digital assets where each unit has the same value (fungible). They are ideal for representing currencies, points, credits, and other assets of uniform value.

What is ERC20 in ISBE

ERC20 in ISBE is an implementation of the ERC-20 standard (EIP-20) that relies on ISBE's Core contracts, providing:

• Role-based access control (AccessControl)
• Pause capability for emergencies (Pausable)
• Ownership management (Ownable)
• Integration with decentralized identity (DID)
• ERC165 support for interface detection

Available Extensions

ISBE offers the following extensions that you can combine based on your needs:

• Base: Standard ERC20 token with basic functionality.
• Burnable: Token destruction.
• Capped: Maximum supply limit.
• Snapshot: Balance snapshots for auditing.
• Controller: Forced administrative control for exceptional cases.

ERC20 Variants

Base - Standard ERC20 Token

Fungible token with basic transfer and approval functions.

Functionality:

• Transfers (transfer, transferFrom)
• Approvals (approve, allowance)
• Balance queries (balanceOf, totalSupply)
• Metadata (name, symbol, decimals)

When to use:

• Simple utility tokens.
• Internal platform credits.
• Access tokens without special requirements.

Initialization:

initializeErc20(
    "My Token",      // name
    "MTK",           // symbol
    18               // decimals
)

Burnable - Token Destruction

Allows burning (permanently destroying) tokens, reducing the total supply.

Additional functionality:

• burn(amount) - Burn own tokens.
• burnFrom(account, amount) - Burn tokens from another address (requires allowance).

When to use:

• Tokens with programmed deflation.
• Buyback and burn mechanisms.
• Dynamic supply management.

Capped - Maximum Supply

Sets a maximum limit on tokens that can exist and provides minting functionality.

Additional functionality:

• mint(address, amount) - Mint new tokens.
• cap() - Query the maximum limit.
• Automatic validation when minting (cannot exceed the cap).

Required roles:

• MINTER_ROLE - To mint tokens.
• CAP_ROLE - To configure the maximum limit.

When to use:

• Tokens with limited supply (e.g., 21M like Bitcoin).
• Prevention of uncontrolled inflation.
• Scarcity guarantee.

Snapshot - Balance Snapshots

Allows creating snapshots of balances at specific times for auditing or governance.

Additional functionality:

• snapshot() - Create a new snapshot.
• balanceOfAt(account, snapshotId) - Balance at a specific snapshot.
• totalSupplyAt(snapshotId) - Total supply at a specific snapshot.

Required roles:

• SNAPSHOT_ROLE - To create snapshots.

When to use:

• Proportional dividend distribution.
• Governance with historical voting power.
• Tax audits.
• Regulatory compliance.

Controller - Forced Control

Provides forced administrative control functions for exceptional regulatory cases.

Additional functionality:

• forceBurn(account, amount) - Burn tokens from any address.
• forceTransfer(from, to, amount) - Transfer tokens between addresses without allowance.

Required roles:

• CONTROLLER_ROLE - For forced control operations.

When to use:

• Exceptional cases requiring administrative control.
• Special regulatory situations.

Note: Forced control functions are designed for exceptional cases. Their use must be justified.

ERC20 System Roles

Role	Permissions	When it is needed
MINTER_ROLE	Mint new tokens	Initial issuance, rewards, supply expansion
CAP_ROLE	Configure maximum limit	Set or modify the maximum supply
SNAPSHOT_ROLE	Create snapshots	Audits, governance, dividend distribution
CONTROLLER_ROLE	Forced control	Compliance with legal mandates
PAUSER_ROLE	Pause/unpause	Emergencies, maintenance, security incidents

Real Use Cases in ISBE

(Use cases of actual deployments in ISBE will be documented here)

General Use Cases

Utility Tokens:

• API access token.
• SaaS platform credits.
• Game tokens.

Loyalty Points:

• Retail loyalty program.
• Community rewards.
• Digital cashback.

Internal Currencies:

• Internal corporate currency.
• Digital vouchers.
• Institutional credits.

Deflationary Tokens:

• Tokens with burn on each transaction.
• Periodic buyback and burn.
• Programmed supply reduction.

---

ERC721: Non-Fungible Tokens

ERC721 tokens are unique digital assets where each token has a differentiated identity (non-fungible). They are ideal for representing certificates, credentials, unique assets, and any item requiring individual identification.

What is ERC721 in ISBE

ERC721 in ISBE is an implementation of the ERC-721 standard (EIP-721) that relies on ISBE's Core contracts, providing:

• Role-based access control (AccessControl)
• Pause capability for emergencies (Pausable)
• Ownership management (Ownable)
• Integration with decentralized identity (DID)
• ERC165 support for interface detection

Available Extensions

• Base: Standard ERC721 token with basic functionality.
• Burnable: NFT destruction.
• Capped: Maximum supply limit.
• Snapshot: Balance and ownership snapshots.
• Enumerable: Enumeration of existing tokens.
• Royalty: Royalties on resales (EIP-2981).
• Consecutive: Optimized mass minting (EIP-2309).
• Controller: Forced administrative control for exceptional cases.

ERC721 Variants

Base - Standard ERC721 Token

Non-fungible token with basic ownership, transfer, and approval functions.

Functionality:

• Secure transfers (safeTransferFrom)
• Standard transfers (transferFrom)
• Individual approvals (approve, getApproved)
• Global approvals (setApprovalForAll, isApprovedForAll)
• Ownership queries (ownerOf, balanceOf)
• Metadata (name, symbol, tokenURI)

When to use:

• Simple NFTs without special requirements.
• Basic digital certificates.
• Unique assets without advanced features.

Burnable - NFT Destruction

Allows burning (permanently destroying) tokens, reducing the total supply.

Additional functionality:

• burn(tokenId) - Burn own NFT.
• burnFrom(owner, tokenId) - Burn NFT from another address (requires approval).

When to use:

• Certificates with expiration.
• Revocable credentials.
• NFTs with a limited lifecycle.

Capped - Maximum Supply

Sets a maximum limit on tokens that can exist and provides minting functionality.

Additional functionality:

• mint(address, tokenId) - Mint new NFTs.
• cap() - Query the maximum limit.
• Automatic validation when minting (cannot exceed the cap).

Required roles:

• MINTER_ROLE - To mint NFTs.
• CAP_ROLE - To configure the maximum limit.

When to use:

• Limited collections (e.g., 10,000 NFTs).
• Certificates with defined slots.
• Scarcity guarantee.

Snapshot - Historical Snapshots

Allows creating snapshots of balances, ownership, and supply at specific times for auditing.

Additional functionality:

• snapshot() - Create a new snapshot.
• balanceOfAt(account, snapshotId) - Balance at a specific snapshot.
• totalSupply(snapshotId) - Total supply at a specific snapshot.
• ownerOfAt(tokenId, snapshotId) - Owner of a token at a specific snapshot.

Required roles:

• SNAPSHOT_ROLE - To create snapshots.

When to use:

• Governance with historical voting power.
• Proportional benefit distribution.
• Tax audits.
• Regulatory compliance.

Enumerable - Token Enumeration

Provides functions to list and enumerate existing tokens.

Additional functionality:

• totalSupplyEnumerable() - Total existing tokens.
• tokenByIndex(index) - Token ID at global position.
• tokenOfOwnerByIndex(owner, index) - Token ID at owner position.

When to use:

• Marketplaces that need to list NFTs.
• Interfaces showing complete collections.
• Systems requiring iteration over tokens.

Note: Enumerable significantly increases the gas cost on transfers and mints. Use only if necessary.

Royalty - Royalties on Resales

Implements the EIP-2981 standard for royalties in secondary markets.

Additional functionality:

• setDefaultRoyalty(receiver, feeNumerator) - Configure global royalty.
• deleteDefaultRoyalty() - Delete global royalty.
• setTokenRoyalty(tokenId, receiver, feeNumerator) - Royalty per token.
• resetTokenRoyalty(tokenId) - Reset a token's royalty.
• royaltyInfo(tokenId, salePrice) - Query royalty.

Required roles:

• ROYALTY_ROLE - To configure royalties.

When to use:

• Digital art with creator royalties.
• Collections with resale commissions.
• Compliance with contracts with artists.

Consecutive - Mass Minting

Allows minting multiple consecutive tokens in a single optimized operation (EIP-2309).

Additional functionality:

• mintConsecutive(to, quantity) - Mint multiple consecutive tokens.

Required roles:

• MINTER_ROLE - To mint tokens.

When to use:

• Initial issuance of large collections.
• Mass distribution of certificates.
• Gas savings on multiple mints.

Controller - Forced Control

Provides forced administrative control functions for exceptional regulatory cases.

Additional functionality:

• forceBurn(owner, tokenId) - Burn NFT from any address.
• forceTransfer(from, to, tokenId) - Transfer NFT without approval.

Required roles:

• CONTROLLER_ROLE - For forced control operations.

When to use:

• Compliance with court orders.
• Asset recovery in fraud cases.
• Revocation of credentials under legal mandate.

Note: Forced control functions are designed only for exceptional cases under legal or regulatory mandate. Their use must be documented and justified.

ERC721 System Roles

Role	Permissions	When it is needed
MINTER_ROLE	Mint new tokens	Issuance of certificates, creation of NFTs
BURNER_ROLE	Burn tokens	Revocation of certificates, destruction of NFTs
CAP_ROLE	Configure maximum limit	Set or modify the maximum supply
SNAPSHOT_ROLE	Create snapshots	Audits, governance, historical record
ROYALTY_ROLE	Configure royalties	Management of resale commissions
CONTROLLER_ROLE	Forced control	Compliance with legal mandates
PAUSER_ROLE	Pause/unpause	Emergencies, maintenance, security incidents

Real Use Cases in ISBE

(Use cases of actual deployments in ISBE will be documented here)

General Use Cases

Digital Certificates:

• University diplomas.
• Professional certifications.
• Academic degrees.

Identity Credentials:

• W3C verifiable credentials.
• Professional licenses.
• Permits and authorizations.

Digital Art and Collectibles:

• Digital art.
• Limited collectibles.
• Digital photography.

Tokenized Assets:

• Real estate.
• Valuables.
• Industrial equipment.

Licenses and Permits:

• Software licenses.
• Access rights.
• Memberships.

---

ERC3643: Regulated Tokens

ERC3643 tokens are used to represent financial instruments requiring strict regulatory compliance. They are designed exclusively for tokenizing securities (shares, bonds, funds) that must comply with financial regulations.

Note: ERC3643 is designed exclusively to represent regulated financial instruments (shares, bonds, investment funds). For utility tokens, use ERC20.

What is ERC3643 in ISBE

ERC3643 in ISBE is an implementation of the ERC-3643 standard that relies on ISBE's Core contracts, providing:

• Role-based access control (AccessControl)
• Pause capability for emergencies (Pausable)
• Ownership management (Ownable)
• Integration with decentralized identity (DID)
• ERC165 support for interface detection

Differences with Standard ERC20

ERC3643 extends ERC20 by adding mandatory regulatory validations:

• Address Whitelist: Only authorized wallets can operate.
• Compliance Rules: Balance limits, volume, restrictions.
• Fund Freezing: Full or partial account freezing.
• Forced Control: Transfers and burns without prior approval.
• Wallet Recovery: Recover tokens from lost wallets.

Available Extensions

• Base: ERC3643 token with basic regulatory functionality.
• Metadata: Dynamic name and symbol update.
• Freeze: Full and partial account freezing.
• Capped: Maximum supply limit.
• Controller: Forced operations without approval.
• Snapshot: Balance snapshots for auditing.
• Recovery: Token recovery from lost wallets.
• Compliance: Rule orchestrator (activates/deactivates features).
• Compliance MaxBalance: Maximum balance limit per account.
• Compliance DayMonthLimits: Daily and monthly transfer limits.

ERC3643 Variants

Base - Standard ERC3643 Token

Regulated fungible token with integrated identity and compliance validations.

Functionality:

• All standard ERC20 operations.
• Mandatory whitelist validation.
• Compliance verification on each transfer.
• Balance and supply queries.
• Metadata (name, symbol, decimals).

When to use:

• Basic regulated financial instrument.
• Security token without special compliance requirements.

Metadata - Metadata Update

Allows dynamic updating of the token name and symbol (regulatory requirement).

Additional functionality:

• setName(string) - Update token name.
• setSymbol(string) - Update token symbol.

Required roles:

• METADATA_ROLE - To update metadata.

When to use:

• Tokens requiring branding changes.
• Compliance with regulatory naming requirements.

Freeze - Account Freezing

Allows full or partial account freezing for regulatory reasons.

Additional functionality:

• setAddressFrozen(address, bool) - Freeze/unfreeze full account.
• freezePartialTokens(address, amount) - Freeze specific amount.
• unfreezePartialTokens(address, amount) - Unfreeze specific amount.
• isFrozen(address) - Query if account is frozen.
• getFrozenTokens(address) - Query partially frozen tokens.
• Batch operations for multiple accounts.

Required roles:

• FREEZE_ROLE - For freezing operations.

When to use:

• Court orders for asset freezing.
• Prevention of movements during investigations.
• Dispute or conflict management.

Capped - Maximum Supply

Sets a maximum limit on tokens that can exist and provides minting functionality.

Additional functionality:

• initializeCap(cap) - Initialize maximum limit.
• setCap(newCap) - Update maximum limit.
• cap() - Query the maximum limit.
• mint(address, amount) - Mint tokens (cap validation).
• batchMint(addresses[], amounts[]) - Mint multiple in batch.

Required roles:

• MINTER_ROLE - To mint tokens.
• CAP_ROLE - To configure the maximum limit.

When to use:

• Securities with limited issuance.
• Guarantee of non-dilution above limit.

Controller - Forced Control

Provides forced administrative control functions for regulatory compliance.

Additional functionality:

• forceTransfer(from, to, amount) - Transfer without approval.
• forceBurn(from, amount) - Burn tokens without approval.
• Batch operations for multiple transfers/burns.
• Auto-unfreeze: Automatically unfreezes necessary tokens.

Required roles:

• CONTROLLER_ROLE - For forced control operations.

When to use:

• Exceptional cases requiring administrative control.
• Special regulatory situations.

Snapshot - Historical Snapshots

Allows creating snapshots of balances and supply at specific times for auditing.

Additional functionality:

• snapshot() - Create a new snapshot.
• balanceOfAt(account, snapshotId) - Balance at a specific snapshot.
• totalSupply(snapshotId) - Total supply at a specific snapshot.

Required roles:

• SNAPSHOT_ROLE - To create snapshots.

When to use:

• Proportional dividend distribution.
• Periodic regulatory audits.
• Historical tax reports.
• Governance with historical voting power.

Recovery - Wallet Recovery

Allows recovering tokens from lost or compromised wallets to new verified wallets.

Additional functionality:

• recoveryAddress(lostWallet, newWallet) - Recover tokens to new wallet.

Required roles:

• RECOVERY_ROLE - For recovery operations.

When to use:

• Loss of private keys.
• Compromised wallets.
• Change of custodian.
• Identity migration.

Compliance - Rule Orchestrator

Central module that manages the activation and orchestration of all compliance rules.

Additional functionality:

• Orchestrates the validation of all active compliance features.
• Executes validations on each transfer, mint, and burn.
• Allows bypass for accounts with COMPLIANCE_ROLE.

Required roles:

• COMPLIANCE_ROLE - To manage features and bypass validations.

When to use:

• Always present in ERC3643 tokens.
• Acts as a central layer of regulatory validation.

Compliance: MaxBalance

Maximum balance limit that each account can have.

Additional functionality:

• initializeERC3643ComplianceMaxBalance(maxBalance) - Initialize limit.
• setMaxBalance(maxBalance) - Update limit.
• getMaxBalance() - Query current limit.
• enableMaxBalance() - Activate validation.
• disableMaxBalance() - Deactivate validation.
• Automatic validation on each transfer and mint.

Required roles:

• COMPLIANCE_ROLE - To configure and activate/deactivate.

When to use:

• Prevention of ownership concentration.
• Compliance with regulatory limits per investor.
• Equal distribution required by law.

Compliance: DayMonthLimits

Daily and monthly transfer volume limits per account.

Additional functionality:

• initializeERC3643ComplianceDMLim(dailyLimit, monthlyLimit) - Initialize limits.
• setDayMonthLimits(dailyLimit, monthlyLimit) - Update limits.
• getDayMonthLimits() - Query current limits.
• enableDayMonthLimits() - Activate validation.
• disableDayMonthLimits() - Deactivate validation.
• Automatic validation on each transfer.

Required roles:

• COMPLIANCE_ROLE - To configure and activate/deactivate.

When to use:

• Anti-Money Laundering (AML).
• Transaction speed control.
• Compliance with regulatory trading limits.

Compliance Validation System

ISBE's Diamond architecture implements a modular compliance system:

• Compliance: Central orchestrator managing rule activation and execution.
• Modular Features: Each rule (MaxBalance, DayMonthLimits) is independent and configurable.
• Dynamic Activation: Features are activated/deactivated without redeploy via flags.
• Automatic Validation: The orchestrator executes validations of active features in each operation.
• Bypass by role: COMPLIANCE_ROLE can jump all validations in special operations.

ERC3643 System Roles

Role	Permissions	When it is needed
MINTER_ROLE	Mint new tokens	Security issuance, capital increases
METADATA_ROLE	Update name and symbol	Branding changes, regulatory requirements
FREEZE_ROLE	Freeze/unfreeze accounts	Court orders, investigations
CONTROLLER_ROLE	Forced transfers and burns	Legal mandates, dispute resolution
RECOVERY_ROLE	Recover lost wallets	Key loss, change of custodian
SNAPSHOT_ROLE	Create snapshots	Audits, dividend distribution
CAP_ROLE	Configure maximum limit	Set maximum issuance
COMPLIANCE_ROLE	Configure and bypass compliance	Regulatory rule management, exceptional operations
PAUSER_ROLE	Pause/unpause	Emergencies, maintenance, security incidents

Real Use Cases in ISBE

(Use cases of actual deployments in ISBE will be documented here)

General Use Cases

Tokenized Shares:

• Private company shares.
• Equity crowdfunding.
• Startup stakes.

Digital Bonds:

• Corporate bonds.
• Tokenized public debt.
• Fixed income instruments.

Investment Funds:

• Real estate funds.
• Venture capital funds.
• Collective investment funds.

---

AssetEventTracker: Asset Traceability

AssetEventTracker allows recording, querying, and auditing events associated with digital assets (tokens, credentials, documents) ensuring immutable traceability, integrity, and regulatory compliance.

What is AssetEventTracker in ISBE

AssetEventTracker is an event logging system that relies on ISBE Core contracts, providing:

• Role-based access control (AccessControl)
• Pause capability for emergencies (Pausable)
• Ownership management (Ownable)
• Integration with decentralized identity (DID)
• ERC165 support for interface detection

Main Features

• Immutable log: Permanent events on blockchain.
• Efficient queries: Search by state, pagination.
• Semantic flexibility: Configurable states per use case.
• Interoperability: Compatible with external verification systems.

Functionality

Functionality:

• State change record (recordState)
• Current state query (getCurrentState)
• Latest asset event query (getLatestAssetEvent)
• Paged event query (getAssetEvents)
• State change validation (isStateChangeAllowed)

When to use:

• Credential lifecycle tracking.
• Non-fungible token traceability.
• Document state change auditing.
• Regulatory event logging.

System Roles

Role	Permissions	When it is needed
ASSET_EVENT_TRACKER_ROLE	Record new states	Authorized issuers, management systems
PAUSER_ROLE	Pause/unpause	Emergencies, maintenance, security incidents

Real Use Cases in ISBE

(Use cases of actual deployments in ISBE will be documented here)

General Use Cases

State Machine Control:

• Multi-stage approval flows.
• Digital asset lifecycles.
• Processes with transition validation.
• State change traceability.

Audit and Compliance:

• Immutable event log.
• Change history.
• Regulatory traceability.

---

HashTimestamp: Timestamping

HashTimestamp provides an immutable, verifiable, and traceable mechanism to record the existence of a document or digital data at a given time by storing its cryptographic hash and timestamp on the blockchain.

What is HashTimestamp in ISBE

HashTimestamp is a decentralized digital notarization system that relies on ISBE Core contracts, providing:

• Role-based access control (AccessControl)
• Pause capability for emergencies (Pausable)
• Ownership management (Ownable)
• Integration with decentralized identity (DID)
• ERC165 support for interface detection

Main Features

• Proof of existence: Proof that a document existed at a specific time.
• Verifiable integrity: Any alteration to the document is detectable.
• Non-repudiation: Immutable record on blockchain as evidence.
• Privacy: Only the hash is stored, not the content.
• Efficiency: Verification without needing to store documents on-chain.

Functionality

Functionality:

• Hash recording with timestamp (timestampHash)
• Existence verification (exists)
• Timestamp query (getTimestamp)

When to use:

• Notarization of legal documents.
• Temporal certification of intellectual property.
• Digital notarization of contracts.
• Evidence auditing.
• Proof of existence of data.

System Roles

Role	Permissions	When it is needed
HASH_TIMESTAMP_ROLE	Record new hashes	Authorized issuers, notarization systems
PAUSER_ROLE	Pause/unpause	Emergencies, maintenance, security incidents

Real Use Cases in ISBE

(Use cases of actual deployments in ISBE will be documented here)

General Use Cases

Proof of Existence:

• Temporal certification of documents.
• Data existence record.
• Integrity proof.

Digital Notarization:

• Temporal timestamping of content.
• Immutable record of hashes.
• Non-tampering verification.

---

Template Usage Flow

1. Choose your template

Review the available templates and select the one that best suits your use case.

2. Configure the parameters

Each template requires initialization parameters based on the type:

ERC20 Example:

{
  name: "My Token",
  symbol: "MTK",
  decimals: 18
}

ERC721 Example:

{
  name: "My Certificates",
  symbol: "CERT",
  baseURI: "https://api.myapp.com/metadata/"
}