ioBuilders Helps Transform Digital Assets on Hedera through Asset Tokenization Studio

Hedera’s Asset Tokenization Studio is a newly launched open-source solution designed to streamline the process of converting real world assets, such as equities and bonds, into digital tokens. Built on the Hedera Hashgraph network, Asset Tokenization Studio leverages Hedera’s unique technological advantages— low latency, and advanced security—enabling fast, secure, and efficient tokenization of assets. Its customizable templates and built-in compliance features simplify the creation, management, and trading of tokenized assets on a decentralized ledger, making it easier for organizations to enhance liquidity, transparency, and regulatory adherence. By utilizing Hedera’s predictable transaction costs and governance by global organizations, Asset Tokenization Studio ensures a scalable and trusted platform for enterprises seeking to modernize asset management through secure and compliant tokenization solutions.

Functionalities

Hedera's Asset Tokenization Studio allows for the deployment and management of equities and bonds out of the box, with the flexibility to be extended to include any other type of real-world asset.

The ERC1400 asset standard serves as the foundation, with additional functionality built on top of it. Some features are common across all asset types, while others are specific to particular asset categories.

Common functionality

Access Control: Roles are defined for every management operation (outlined below), ensuring that only accounts with the appropriate roles can execute these operations.

Cap: The number of assets that can be minted is limited to a maximum amount.

Control List: A blacklist or whitelist can be activated for specific assets, preventing certain accounts from transferring or receiving those assets.

Controller: Authorized accounts can enforce transfers and redemptions from token holders. This feature is inherited from the ERC1400 standard.

Documentation: Links to off-chain documents (e.g., PDFs, images) can be added to an asset. This functionality is also inherited from the ERC1400 standard.

Partitions: Assets can be divided into partitions. Tokens within the same partition are fungible with each other, but tokens in different partitions are not. While this feature can be useful in specific scenarios, assets can also be deployed with a single partition for simplicity. This is inherited from the ERC1400 standard.

Lock: Users' assets can be locked for a specified period, during which they remain in the user's balance but cannot be transferred or redeemed.

Pause: The asset can be paused, disabling all operations until it is unpaused. This feature is intended for use in emergency situations, such as a hacking attempt.

Snapshots: Token holder balances can be captured at any point in time and stored on the blockchain, allowing other smart contracts to access balances from a specific moment in the past.

Equities functionality

Dividends: Dividends can be scheduled for a future date. The system requires a record date, execution date, and the dividend amount per unit of the asset. The record date triggers an automatic on-chain snapshot of all token holders' balances at that time. Both the execution date and the dividend amount are stored on-chain, allowing external systems to use this information, along with the snapshot, to execute the actual dividend payments.

Voting Rights: Voting rights function similarly to dividends. A record date and arbitrary data are provided. The record date triggers an automatic on-chain snapshot, which captures the token holders' balances. These balances can be used by external systems (on-chain or off-chain) as voting power in election processes. The arbitrary data field allows for storing any information related to the voting process for transparency.

Bonds functionality

Coupons: Bond coupons are similar to equity dividends, with a record date, execution date, and a coupon rate, which represents the annual interest rate (percentage). A unique feature of bond coupons is the ability to automatically set future coupon dates at the time of the bond’s initial deployment. If a coupon frequency and a first coupon record date are provided, the system will automatically calculate all subsequent coupon record dates.

Technical overview

Solution’s Architecture

The overall architecture of the solution is divided into three components:

1. Smart Contracts: Deployed on Hedera, these contracts enforce the functionalities mentioned above, manage balances, and handle other on-chain operations.

2. TypeScript SDK: This SDK allows any user-facing application to seamlessly interact with the smart contracts. 3. React Front End (DApp): Built using the SDK, this user-friendly interface provides an intuitive and efficient way for users to deploy and manage Real-World Assets (RWAs).

Smart Contracts

The most compelling aspect is the robust set of smart contracts designed to support the solution and enforce management and compliance restrictions directly on-chain.

Architecture

The solution implements a tiered architecture, divided into three distinct layers as follows:

Layer 1: This foundational layer contains all the common functionality for assets (described earlier). It extends the ERC1400 standard by adding modular components, each representing a specific feature, such as access control, cap limits, control lists, and more. However, this layer alone cannot be used to deploy any assets, as it lacks the necessary functionality for real-world assets (RWAs), such as dividend management for equities.

Layer 2: At this level, actual generic assets are defined. Currently, only equities and bonds have been implemented. This layer inherits all functionality from Layer 1 and introduces additional features tailored to each asset type (as described earlier). Nevertheless, these generic assets are not fully ready for real-world deployment, as they do not yet account for jurisdiction-specific regulations and requirements, which are often necessary for compliance.

Layer 3: The third and highest layer allows for the customization of Layer 2 generic assets to meet the regulatory requirements of specific jurisdictions. This customization reuses all the generic functionality provided by the lower layers. For instance, U.S. regulations like Reg S and Reg D have been incorporated, with regulatory definitions stored on-chain. Some of these rules, such as Reg D's "release hold period," can even be enforced directly on-chain.

Each layer can be extended further:

Layer 1 can be expanded to introduce additional common functionality.

Layer 2 can be extended to add new generic asset types or enhance existing ones.

Layer 3 can be modified to support new jurisdictions or extend jurisdiction-specific functionality.

Additional layers can also be implemented on top of Layer 3 if needed to meet further requirements.

Factory pattern

Assets are deployed through a pre-deployed factory smart contract, although anyone has the option to deploy their own factory and use it.

When someone wants to deploy a new equity or bond, they can invoke the corresponding deployment method on the factory. This action will deploy a new smart contract on-chain that represents the asset. The newly deployed contract is actually a “resolver proxy” (explained in

detail below). This means that while all asset-related data (e.g., balances, roles, etc.) is stored in the contract's local storage, the actual business logic resides elsewhere.

The pre-deployed factory is actually a transparent proxy managed by a proxy admin, enabling the owner to update its functionality or fix bugs as needed. It's important to note that while the factory is responsible for deploying new assets, it has no control over the assets once they are deployed.

Diamond-Resolver pattern

To avoid code duplication on the DLT, bypass the 24KB size limitation of smart contracts, and ensure code upgradeability, the “diamond resolver” pattern is employed.

This pattern is very similar to the traditional diamond pattern, where a proxy delegates incoming calls to different implementation contracts, known as facets, based on the function selector of the incoming call. However, it introduces a key enhancement that makes it particularly suited for the Real-World Asset (RWA) use case, where potentially millions of assets may be deployed on-chain: unlike regular diamond proxies, the diamond loupe and diamond cut functionality are centralized in a single resolver smart contract. When a proxy receives an incoming call, it contacts the resolver to determine which facet it should delegate the call to.

This approach allows for seamless business logic updates across multiple assets. Instead of updating each individual proxy, admins only need to update the resolver. All proxies that reference the resolver will automatically reflect the updated business logic.

While the full details of the diamond-resolver pattern are beyond the scope of this article, it’s worth noting that if an asset’s admins prefer to stick with a specific version of the business logic rather than follow the latest updates in the resolver, they can configure the resolver-proxy to lock to a particular version.

The resolver contract, like the factory contract, is a pre-deployed smart contract (though users have the option to deploy their own resolver if needed). It operates as a transparent proxy managed by a proxy admin, allowing the owner to update its functionality or fix bugs as required. The management of facet addresses is restricted to authorized accounts to ensure security and control.

Unlike the factory, the resolver plays a crucial role in the ongoing operation of deployed assets, as it dynamically determines how they function. This makes its management critical to the proper functioning of the entire solution.

Storage structure

Most modules require persistent storage for variables within the resolver proxy's storage. To prevent conflicts and the associated security and functionality risks, it is essential to properly isolate each module’s variables from those of other modules.

The solution to this challenge is the use of “unstructured storage”, which operates as follows:

Each module is assigned a unique starting storage slot, similar to an offset, which is determined by hashing the module’s unique Fully Qualified Domain Name (FQDN). The module’s first variable is stored at this calculated slot, and subsequent variables are stored sequentially in ascending order from there.

Conclusion

The Asset Tokenization Studio is a highly flexible and transparent solution for deploying real-world assets (RWAs) on-chain. Its layered architecture, spanning from common functionalities to jurisdiction-specific customizations, provides a robust foundation that can be expanded and upgraded as needed. This structure allows for the seamless integration of new asset types or regulatory frameworks, making it adaptable to a wide range of use cases. Moreover, the built-in control lists and compliance mechanisms ensure that the Asset Tokenization Studio remains fully adaptable to evolving regulations, offering organizations the ability to maintain control over assets while ensuring compliance. As a result, the Asset Tokenization Studio is an ideal technical solution for enterprises looking to modernize asset management in a secure, scalable, and regulation-friendly environment.