4 Digital Assets APIs

Oracle Blockchain Platform Enterprise Edition for Besu provides digital assets APIs that you can use to work with smart contracts.

The digital assets APIs are Solidity-based, reusable components for developing, testing, and deploying digital asset smart contracts on Besu. You can use the APIs to implement domain-specific token applications while retaining consistent approaches to token configuration, identity and access controls, upgradeability, and governance.

The core of any Oracle Blockchain Platform Besu application is one or more smart contracts that define the states of a digital asset and the business rules that govern how it is created, transferred, held, redeemed, and managed. Because these rules directly affect the asset life cycle, contracts must be designed, reviewed, and tested before deployment. Each of the two APIs supports a different token standard.

Token Standard	Primary Use	Example Use Cases
ERC-20	Fungible assets where each token is interchangeable with every other token.	Payments, stablecoins, deposit tokens, settlement tokens, and wholesale CBDC assets.
ERC-1155	Fungible assets and non-fungible (NFT) assets. Multiple token types are supported in the same smart contract. Fractional tokens (shares) are supported.	Tokenized assets, collections, and unique digital assets.

The APIs provide configurable base contracts and supporting libraries that you can inherit from or compose into your own Solidity contracts. Depending on the selected token model, applications can incorporate capabilities such as minting and burning, controlled transfers, holds, approvals, identity-aware permissions, and policy enforcement. The APIs also support upgradeable contract patterns and governance-controlled lifecycle operations if these are required by an application.

The following diagram illustrate the capabilities of the extended ERC-20 token standard implementations.

The following diagram illustrate the capabilities of the extended ERC-1155token standard implementations.

Pluggable Access Control Modules

You can select account and policy modules to align token operations with an application's access-control model. Specifically, the API includes contract and account versions for both the ERC-5982 and the EIP-6617 permission models. These modules connect token contracts to identity and policy gateways, allowing applications to apply role-aware and organization-aware authorization without embedding a single access control implementation in every token contract.

You can choose the account variant and policy capabilities that suit your application, and then use the common account interfaces from the token contracts. This separation keeps token business logic focused on the asset life cycle while allowing access policies to be configured, extended, or exchanged as application requirements evolve.

Contract Composition Model

The Solidity tokenization layer uses a contract composition model. You select an upgradeable token base, add the behavior modules required by the asset lifecycle, and then pair the token with an appropriate account and access-control module. This model supports capabilities such as minting, burning, holds, and approvals without requiring every token to expose every operation. You can use strict composition or mixin / compatibility composition.

Strict composition is appropriate when the supported token operations are known at design time. Developers inherit from a narrow base contract that supports only specific capabilities. Only selected operations are included in the contract ABI. During initialization, the token configuration is validated against the selected capability profile, so that incompatible behaviors or minting and burning modes are rejected.

Mixin / compatibility composition is appropriate when runtime flexibility and a broader, reusable set of token operations are more important. Developers inherit from a fuller base contract, with runtime behavior flags determining which optional policies are active. The full ABI remains available, while behavior-specific operations enforce the enabled configuration when they are called.

Choose the narrowest composition that meets your product requirements, and then combine it with the required access-control account module and product-specific business logic. Strict composition produces a smaller, more intentional ABI and prevents unsupported operations from being exposed. Mixin / compatibility composition provides a broader foundation for applications whose behavior must be configured at runtime.

Use the APIs as starting points rather than as fixed applications. Typically a team selects the ERC-20 or ERC-1155 foundation that matches the required asset model, configures the behavior and access controls, and then implements specific business logic to support the asset life cycle. This enables a common contract foundation while allowing each application to reflect its own participants, authorization rules, and operational processes.

The APIs are for Solidity developers working directly with the ERC-20 and ERC-1155 contract sources. You can develop and test applications by using Hardhat, and then deploy to an Oracle Blockchain Platform environment by using the deployment approach appropriate for the application.

Governance Flow for Deploying and Upgrading Contracts

Governance controls when a deployed contract becomes usable and which UUPS implementation upgrades are authorized. Composed projects deploy and connect the account and token proxies, and then attach both to a governance contract and governance UUID. The proxies are deliberately inactive until the configured governance flow activates them, as shown in the following life cycle:

1. Deploy account and token UUPS proxies.
2. Set account/token context and governance context. Proxies remain inactive.
3. Submit deployment intent with proxy, implementation, and code-hash components.
4. • No-Op: Accepted immediately, components activated.
   • Governed: Collect policy approvals, then components are activated after approval.

Governance Models

The two supported governance models are No-Op and Governed.

No-Op does not remove the governance life cycle from the application. It implements the same governance interface, records the intent, and approves deploy and upgrade checks automatically. Do not use the No-Op model as a production approval mechanism.

The Governed model does not allow the deployer, Blockchain App Builder, or a CLI script to bypass approvers. The required approvers, threshold, deadline, and approval process are defined by the deployed governance and policy configuration.

The following table summarizes the behavior of the two governance models.

Governance Model	Purpose	Deployment Behavior	Upgrade Behavior
No-Op	Local development, demos, and other situations where governance approval is intentionally bypassed.	The proposeDeployIntent function accepts the intent and activates its components immediately.	The upgrade intent is accepted without policy approval; the operator still runs the prepared upgradeToAndCall execution step.
Governed	Environments that require policy-based review and approval.	The intent remains pending until the configured policy receives the required approvals before its deadline; only then are components activated.	The proposed implementation and its code hash must receive the required authorization before the execution step can consume the implementation and upgrade the proxy.

When you build a project with Blockchain App Builder, the following governance building blocks are already supplied:

• The IDAContractGovernance interface and the NoOpGovernance and GovernedGovernance implementations.
• Governance context and activation support on generated token and account contract bases, including setGovernanceContext, getGovernanceContext, and activateFromGovernance methods.
• UUPS upgrade authorization through the API’s UpgradeAuthorizationLib method, which calls the configured governance contract during the _authorizeUpgrade process.
• Generated deployment and upgrade scripts that set governance context, prepare intent data, record manifests, and submit intent requests.

Because these building blocks are already supplied, a standard composed project does not require you to write extra Solidity governance hooks for its generated token and account contracts. You must still choose and deploy or obtain the appropriate governance contract, configure the UUID and policy and provide their addresses to the deployment/upgrade workflow, and undergo the approval process for Governed environments. For an Oracle Blockchain Platform Besu network, a governance contract is deployed as part of instance provisioning.