Create and Compose a Digital Assets Project

You can use Blockchain App Builder to create and compose a smart contract project to work with digital assets.

Blockchain App Builder For Besu generates a self-contained Hardhat project for ERC-20 or ERC-1155 tokens. You choose the token standard and supported capabilities in the extension. The composer function in Blockchain App Builder copies the matching SDK, creates the concrete Universal Upgradeable Proxy Standard (UUPS) token contract, and adds scripts to deploy and upgrade the smart contract.

Use the composer function to create a project where the token ABI and account contract are derived from an explicit capability profile. It does not deploy a token when it creates the project, and it does not run the npm install command automatically

Before you can create and deploy a digital assets project, you must install the Blockchain App Builder for Besu extension and open a Visual Studio Code workspace. To deploy the generated project, Node.js and npm must be installed. You also need an accessible Hardhat or Besu network, an account capable of deploying contracts, and an existing governance contract and governance UUID.

The generated deployment scripts require GOVERNANCE_ADDRESS and GOVERNANCE_UUID environment variables. The composer function links this governance context to the generated account and token proxies; deployment activation remains subject to the configured governance workflow.

Create a Project

  1. Open the Modules view in the Blockchain App Builder For Besu activity bar.
  2. Select Open Module Composer and then select the Module Composer tab.
  3. In Create New Hardhat Project, enter the project name and choose its parent folder. The coompose function creates the project using the following directory structure: <parent_folder>/<project_name>.

    The project name can contain letters, numbers, periods, hyphens, and underscores, but not double periods (..). The project name must start with a letter or underscore and can contain only letters, numbers, and underscores. The destination must be empty. The compose function will not overwrite a non-empty project folder.

  4. Select the token standard, composition mode, and capabilities, which are described in the following section.
  5. Enter a Solidity contract name. For example, enter DepositToken.
  6. Review the generated composition preview, and then select Generate Package.

When project generation is successful, the extension imports the project into the Contracts view.

Composition Modes

By default, the compose function uses strict composition mode. Both modes are supported for both token standards.
  • Strict composition mode: The generated token inherits a base that exposes only the selected optional capabilities. To add any capabilities that are not selected during composition, an implementation upgrade is required.
  • The generated token inherits a full-surface compatibility base. Runtime configuration controls applicable behaviors, but the broader method surface remains in the ABI.

Compose an ERC-20 Project

Select one required identity-permission module:
  • ERC-5892: Standard access control back end.
  • ERC-6617: Bit-based access control back end.

Then, configure the capabilities that are described in the following table.

Input Values Notes
Minting Disabled, Direct, Approval required Approval required adds the request/approval workflow.
Burning Disabled, Direct, Approval required Approval required adds the request/approval workflow.
Holdable On or off Supports hold workflows.
Roles On or off Automatically enabled for approval minting, approval burning, or holdable workflows because they require NOTARY authorization.
Daily Limits On or off Selects an account variant with or without daily-limit enforcement.
Multi-Level Approvals On or off Enables account and approval policies and approval-sequenced hold execution. It automatically enables the holdable capability.

The following behaviors are always part of an ERC-20 generated profile: transferable behavior, delegated operations, pausable behavior, and governance approval flow. Roles are also part of the profile when the compose function has automatically enabled them.

For example, a direct-mint, direct-burn token with no holds generates the strict base ERC20DirectMintBurnUpgradeable. Enabling multi-level approvals instead selects a holdable, multi-level approval base and deploys the additional ERC20MultiLevelApprovalHelperLib library.

Compose an ERC-1155 Project

ERC-1155 projects use the ERC-5982 access control back end by default. Select one asset type:

  • Fungible token: Token classes with a fungible supply.
  • Whole NFT: Non-fractional NFT classes.
  • Fractional NFT: NFT classes with fractional ownership.
  • Combined fungible and non-fungible tokens: Classes for both fungible tokens and NFTs.

Configure direct minting and burning as enabled or disabled. Minting and burning with approvals are not supported for ERC-1155. The compose function always includes transferable behavior, delegated operator approval (setApprovalForAll and isApprovedForAll), pausable behavior, governance, and ERC-5982 access control.

You can enable roles. For NFT asset types, you can also enable lockable NFTs. Locking is not available for fungible tokens and is disabled when both minting and burning are disabled. Divisible/indivisible behavior is derived from the selected asset type, not entered separately. Daily limits, holdable behavior, and multi-level approvals are not supported.

The combined ERC-1155 profile uses the full-surface ERC1155CombinedTokenUpgradeable base even when you select strict composition. Other strict profiles use an asset-type and mint/burn-specific base.

Generated Project Contents

The compose function creates the following project structure.

<project>/
├── contracts/
│   ├── obp-sdk/                         # copied ERC-20 or ERC-1155 SDK source
│   └── <ContractName>/
│       ├── <ContractName>Upgradeable.sol
│       └── generated.manifest.json      # selected profile and generated paths
├── scripts/
│   ├── deploy/<contract-name>/deploy-<contract-name>.ts
│   └── upgrade/
│       ├── upgrade-<contract-name>.ts
│       └── upgrade-<contract-name>-account.ts
├── .obp-bap/
│   ├── plugins/                         # bundled Hardhat plugin archives
│   └── project.json                     # Composer project metadata
├── config/hardhat-env.ts
├── hardhat.config.ts
├── package.json
└── README.md

The SDK that is located under contracts/obp-sdk/ is copied into the generated project and is owned by the project after generation. The manifest records the token standard, composition mode, selected base and account contracts, and the full normalized capability profile

Troubleshooting Generation Errors

Message or Condition Resolution
Select one identity-permission module Choose ERC-5982 or ERC-6617 for ERC-20.
Contract name must start with a letter/underscore Use a valid Solidity identifier.
Project name is required or unsafe name Supply a simple project name without path separators or double periods (..).
Choose a parent folder Select an absolute parent folder in the composer.
Target folder exists and is not empty Choose a new project name or an empty destination. The compose function will not overwrite projects.
ERC-1155 approval-based minting or burning is not supported Choose Disabled or Direct for ERC-1155 minting and burning.
GOVERNANCE_ADDRESS and GOVERNANCE_UUID are required Configure both values before running the generated deploy script.

After you generate a contract project, you can use the imported project in the Contracts view to compile, deploy, and open deploy or execute forms. Keep the generated manifest with the contract; extension tools use the manifest to pair the generated token and account ABIs with the selected composer profile.