Build a real-world asset tokenization solution on AWS with Fireblocks

Tokenizing real-world assets into digital representations is forecasted to reach a substantial total addressable market¹ and render considerable cost-saving opportunities². A digital asset in the context of financial services refers to a digital representation (or “digital twin”) of an underlying financial asset. Such digital assets often take the form of digital tokens typically implemented and operated on, but not exclusively, a blockchain or similar distributed ledger technology (DLT). On such a platform, the tokens can be issued, distributed, and traded as financial instruments themselves on a secondary market. AWS customers across a wide range of industry sectors are actively exploring how this technology can reduce operating costs, create new markets, and develop innovative products with new revenue streams. For a more in-depth introductory overview of tokenization, see Build a digital asset tokenization framework for financial services use cases using Amazon Managed Blockchain – Part 1.

In this use case, a transfer agent facilitates the issuance and distribution of digital tokens, making sure each token accurately represents the value and rights of the underlying assets, while also maintaining records of ownership and managing transactions. Digital asset custody refers to the secure storage and management of digital assets, and typically requires specialized infrastructure, including secure storage solutions, private key management, and adherence to evolving regulations around digital assets.

In many instances, third-party custodians or dedicated digital asset custody providers—such as banks, fintech companies, or tokenization solution providers such as Fireblocks—handle custody, allowing transfer agents to focus on the issuance and transfer business processes. This division of responsibilities makes sure digital asset custody is managed by entities with the necessary security protocols, legal oversight, and technical expertise to safeguard these assets.

Fireblocks is an enterprise-grade platform that provides secure infrastructure for moving, storing, and issuing digital assets, empowering financial institutions, Web3 companies, and payment providers to scale their digital asset operations. The solution architecture outlined in this post strategically integrates Fireblocks’ security and token lifecycle management with a variety of AWS services, delivering end-to-end protection, scalable operations, and streamlined governance for diverse tokenization use cases.

The architecture presented in this post is not meant to serve as a singular prescriptive implementation guide, as multiple institutional brokers may implement their corresponding infrastructure in ways which differ according to their specific business and technical requirements. The solution architecture presented in this post should be regarded as an illustrative example which demonstrates how existing technical infrastructure of a financial services enterprise such as a bank or an asset manager issuing a tokenized digital asset can interface with a specialized ISV technology provider, in this case Fireblocks, via AWS to participate in an industry wide tokenization network utilizing public distributed ledger technology.

The tokenization business use case

The use case focuses on tokenizing a financial asset sold by a financial institution, such as a hold held in the custody of the bank with fractional amount of ownership being issued by the bank and traded by participants of the tokenization network. The tokens would represent a bearer claim on an amount of the underlying asset as held by the custodian bank. By digitizing fractional ownership of such an asset as tokens on a decentralized system of record, multiple organizations can participate in the lifecycle of the tokenized asset without intermediaries, thus reducing costs and increasing efficiency. This use case, depicted in the following diagram, illustrates how a financial institution acting as transfer agent platform provider can provide a cryptographically secure, peer-to-peer record of ownership and facilitate a purely electronic secondary market for trading these digital assets.

This is a conceptual implementation which would enable a custodian institution acting as a transfer agent to issue, transfer, and redeem tokens on the decentralized network. The following diagram shows an overview of the participants involved in a digital asset tokenization lifecycle.

Figure A – An overview of the asset tokenization use case example

In this use case, for the sake of simplicity, a single transfer agent handles both issuance and custody functions. This could represent the role of a global investment bank operating in capital markets, for example. The architecture also demonstrates how asset ownership records on a distributed ledger can be seamlessly integrated with traditional order systems within the enterprise’s core infrastructure.

For the purposes of this post and simplicity, only issuance, transfer, and redemption workflows are considered:

• Issuance – The process of issuing a new token to an identified potential owner consists of first verifying the customer for KYC (Know Your Customer) and AML (Anti-Money Laundering), establishing the market price of the commodity, submitting an order for the commodity, and issuing (or “minting” in distributed ledger terms) a new token to represent the new owner’s ownership of an amount of the asset.
• Transfer – The ownership of the asset is transferred from one owner to another, where both owners are known and validated to both the issuer and the platform. The actual transfer is conducted on smart contracts on the distributed ledger, and corresponding “off-ledger” records are updated accordingly after the ledger transaction has been confirmed.
• Redemption – To redeem their tokens, the token holder initiates a redemption transaction on the blockchain network. This transaction instructs the token issuer or a designated redemption mechanism to exchange the tokens for the underlying asset or service. After redemption, the redeemed tokens are typically removed from circulation, or retired from the blockchain using mechanisms such as token burning.

Solution architecture overview

The following diagram depicts a conceptual solution architecture that spans on-premises applications, applications on AWS and the Fireblocks platform. Only the key functional aspects relevant to the core tokenization workflows of issuance, transfer and redemption are shown, however, this architecture can be extended to support a variety of other workflows. General infrastructure considerations such as high availability and disaster recovery, although critical considerations, are not specifically discussed in detail in this post. For guidance on those topics, refer to the AWS Well-architected Framework.

Figure B – Reference architecture for tokenization application on AWS with Fireblocks

This solution architecture supports two primary functional workflows:

1. Tokenization request flow: Requests to perform a tokenization action.
2. Tokenization response flow: Responses from the execution of the requested action.

These two functional workflows are described in detail in the following section, with references to the corresponding number icons on the architecture diagram in parentheses.

Tokenization request flow

The solution is designed to serve the breadth of tokenization action requests initiated by existing mission-critical systems, such as order systems, liquidity feeds, KYC/AML and regulatory reporting systems (1). This external infrastructure is integrated into the Amazon VPC hosting the AWS tokenization application infrastructure via AWS Direct Connect, supported by an Application Load Balancer (2).

Tokenization action requests originating from the external infrastructure, such as minting of new tokens, are received and processed by a serverless application implemented using AWS Lambda (3), which performs additional message validation and transformation prior to publishing a corresponding message to an Amazon Simple Queue Service (Amazon SQS) (4). Concurrently, external data feeds (such as price / liquidity / market data) are “subscribed” to by a stateful long-running process such as a containerized application running on AWS Fargate for Amazon Elastic Container Service (Amazon ECS) and written to a suitable data store such as Amazon Aurora (20). An action identifier is then assigned in order to correlate requests and responses.

Next, a containerized tokenization application (5) receives a message to perform an action from the SQS queue (4), and retrieves, where required, real-time data (e.g. market price) for the tokenization action from the continually-updated data store or cache.

A new transaction is then invoked by the Tokenization Application, which interfaces with the Fireblocks Tokenization Engine (7). The Fireblocks API gateway checks that the API key is valid and that the request is properly signed with a preconfigured private key (6). Once authorized, the request is sent to the Fireblocks Core application for processing, where the Fireblocks Policy Engine (8) will automatically apply the relevant Transaction Authorization Policy (TAP) ruleset to determine which actions to allow and which to deny.

Tokenization response flow

All on-chain tokenization transactions are generated by the Fireblocks Tokenization Engine, which supports the full range of on-chain lifecycle events from minting through to burning, supporting both Fireblocks-native and third-party smart contracts.

Once the Fireblocks Policy Engine (8) has validated that the transaction meets the Transaction Authorization Policy (TAP) requirements, it is placed in the queue for signing; applicable Approval requirements (see the Transaction Approval Callback Handler detailed below) are processed, following which the Signing Engine (9) checks for available cosigner groups and selects one for the signing. Within the Fireblocks Workspace settings, customers can use API webhooks (10) to monitor all stages of a transaction and track their respective statuses. The Co-Signer gateway (11) monitors the queue for messages relevant to a specific user pair and co-signer. When it finds a matching message, the Customer API Co-Signer (12) retrieves the message, signs it and sends it back to the Co-Signer gateway. The API Co-Signer is a customer-owned component that is installed and hosted within the customer’s environment. In this instance, this is hosted in AWS using a Nitro-capable ECS.

The Enclaved Co-Signer leverages AWS Nitro Hypervisor technology and attestation mechanisms to enhance security. It runs the proven Fireblocks MPC signing algorithm, ensuring robust and secure transaction signing (13).

The AWS-compatible API Co-Signer uses a Customer Managed Key (CMK) within AWS Key Management Service (AWS KMS) (14) to securely encrypt the secrets.key file. This file plays a crucial role in encrypting the API Co-Signer’s secrets database, which includes a set of keys required to approve transactions based on Transaction Authorization Policy (TAP) rules, as well as various administrative configurations and MPC key shares for secure multi-party computation processes.

The proposed architecture features a Transaction Approval Callback Handler (15) that acts as an intermediary between the transaction and the customer. It receives secure approval requests from the API Co-Signer and responds by either approving or rejecting transactions. Once a transaction is fully approved, a message is placed on Amazon SQS for consumption by other application services. One such service is the Regulatory Reporting and/or KYC/AML Service (17), which is invoked as part of a callback from Fireblocks to perform specific KYC/AML checks as required by the platform provider. The reporting service records events which are required for regulatory reporting and would typically be communicated to core regulatory reporting services. Additionally, reconciliation between the off-chain record of asset transactions and the transactions recorded on-chain would be performed by this service. This service would also verify the correctness of operations performed on the blockchain by Fireblocks, utilizing a managed blockchain service such as Amazon Managed Blockchain (19). The solution architecture seamlessly integrates with both private and public distributed ledger technologies (DLT) through industry-standard Remote Procedure Call (RPC) interfaces. For private ledger implementations (18), including Hyperledger Besu, Fireblocks offers dedicated integration support through professional services engagements. Deployment time for such can be significantly reduced by leveraging AWS Node Runners’ Hyperledger Besu blueprint, which provides an infrastructure-as-code template for deploying a private network on AWS.

At various points in the tokenization and signing processes within Fireblocks, callbacks (16) are executed in order to provide the custodian / provider architecture an opportunity to perform actions relevant to the processing flow within Fireblocks.

Supporting AWS Services

Several Supporting AWS Services that operate as global or regional services are depicted at the bottom of the architecture diagram (20) illustrating their availability to the various components of the architecture. Amazon Aurora serves as a relational database for off-chain states with the added benefit of cross Availability Zone (AZ) replication, automated failover and more. Logging, auditability and observability are provided by services such as Amazon CloudWatch and Amazon Simple Storage Service (Amazon S3), and Fireblocks API keys can be managed with AWS Secrets Manager.

Discussion of key architectural aspects

Tokenization lifecycle requests

All tokenization write interactions are controlled by the tokenization service (Step 6 in the preceding architecture workflow). This spans the full lifecycle of the digital asset, from deployment (creation), configuration, issuance (minting), trading, to redemption (burning). For example, to issue more of our digital commodity, the tokenization service invokes a new transaction using the Fireblocks API.

Critical to the security and authorization of these tokenization requests is the Fireblocks Transaction Authorization Policy (TAP), which allows you to define rules around who is allowed to initiate, approve, or sign transactions within their workspace. When a transaction is initiated, the Policy Engine automatically applies the TAP rules to determine the required approvals and signatures. After passing TAP validation, the transaction is placed into a queue for the signing process. The Fireblocks Signing Engine then checks for available co-signer groups and selects one to complete the signing process. The transaction remains in a pending signature status until the necessary signatures are collected, making sure all actions are authorized according to the customer’s predefined security policies.

Integrating Fireblocks webhooks for transaction lifecycle monitoring

After a tokenization request is initiated, Fireblocks provides real-time status updates throughout the lifecycle of the transaction using API webhooks, often referred to as callbacks. These callbacks allow the application architecture to track the status of a transaction at key stages, such as when the transaction is created, pending signatures, or finalized. This real-time visibility is critical for applications that need to maintain synchronization with Fireblocks or invoke additional workflows based on transaction status.

Fireblocks also provides a retry mechanism to make sure alerts are delivered even if the initial delivery fails, making these webhooks reliable for automated processes. For enhanced security, Fireblocks sends events to your webhook endpoint URLs associated with the workspace as part of a POST request with a JSON payload. To validate Fireblocks webhook events, you can verify the signature attached in the request header. For more information, see Configure Webhook URLs.

MPC co-signing with Nitro

In this architecture, the API co-signer, deployed on Nitro capable ECS container instances, handles the signing process within a secure enclave. AWS Nitro Enclaves provides hardware-level isolation, which makes sure sensitive processes, including cryptographic signing, are securely isolated from the host environment and other applications running on the system. This adds an additional layer of security, particularly important in environments handling digital assets and financial transactions. When a transaction requires signing, the Fireblocks Signing Engine communicates with the co-signer, which then retrieves the necessary key shares stored within AWS KMS and performs the signing operation using the multi-party computation (MPC) algorithm.

MPC is a cryptographic technology that allows multiple parties to use their own private data to evaluate a computational problem without ever sharing their secret information with the other parties. This means that private keys are broken into shares, encrypted, and divided among multiple parties, which guarantees that there is no single point of compromise. The MPC signing process takes place entirely within the Nitro Enclave, making sure the private key remains shielded from exposure, even during the signing process. This approach maintains the integrity of the transaction while minimizing the risk of key compromise. To learn more about building secure MPC wallets using Nitro Enclaves, see Build secure multi-party computation (MPC) wallets using AWS Nitro Enclaves.

Fireblocks API co-signer callback handler (optional)

The Fireblocks API co-signer callback handler plays a key role in the application architecture, allowing transactions to be securely approved or rejected based on predefined rules, including compliance checks like KYC/AML policies. After a transaction is initiated and reaches the stage where it requires approval, the co-signer callback handler is invoked to perform the necessary validations before moving forward with signing.

The co-signer callback handler interacts with the customer’s backend systems to enforce business logic and regulatory compliance. For example, it can query external KYC/AML systems to verify the identity of the parties involved in the transaction, maintaining compliance with financial regulations. Based on the results of these checks, the handler can either approve the transaction for signing or reject it if it fails to meet the criteria. This step is critical for companies that need to make sure their tokenization processes are compliant with global or local financial regulations.

If the transaction is approved, the signing process moves forward, where the Fireblocks Signing Engine selects the required co-signer group to complete the MPC signing process. This makes sure all signatures are obtained securely and only after all necessary validations.

For detailed guidance on setting up the API co-signer callback handler, see Create API Co-Signer Callback Handler.

Digital asset custody

This architecture uses Fireblocks as a direct custody platform that provides a self-custody model built on robust security principles. The Fireblocks custody platform never (not during key generation, transaction signing, or backup) has access to the client’s private key data. Learn more about custody at Fireblocks on the direct custody page.

Key security and generation

We use Fireblocks’ implementation of MPC-CMP signing, a peer-reviewed cryptographic algorithm that eliminates single points of failure by distributing key shares across multiple parties.

With MPC-CMP, the private key is broken up into shares, encrypted, and divided among multiple parties. Foundational to this solution is that the key material data (for at least one of the three shards) is generated, secured, and operated inside a client-managed Nitro enclave.

As for key management, the generation of a new key is attributed to a Fireblocks API user, which in turn is paired with a client-generated RSA 4096 key pair allowing for integration into the Fireblocks SDK. API users can be deleted, voiding the utility of the shard in question, should it be required.

In reference to recovery, the key material data as secured in the enclave can’t be recovered. Instead, Fireblocks makes available recovery for the workspace (the Fireblocks tenant) seed, allowing for elliptic curve-based key derivation.

Conclusion

In this post, we presented an example conceptual solution architecture for real-world asset tokenization which leverages AWS cloud services to integrate Fireblocks tokenization SaaS platform with existing financial services infrastructure. By using innovative and novel technologies, such as distributed ledger technology combined with well-architected, secure and resilient cloud architecture patterns, this approach not only demonstrates the feasibility of asset tokenization but also highlights its potential to enhance efficiency, transparency, and accessibility in today’s digital economy. As businesses continue to explore the possibilities of blockchain, this architecture serves as a solid foundation for more complex and scalable tokenization solutions in the future.

For more information on how AWS and Fireblocks can assist you in deploying solutions such as outlined in this blog, reach-out to us. For more information on blockchain and Web3 on AWS, you may contact our Web3 team, contact us at web3-contact@amazon.com. For more information on Fireblocks, contact info@fireblocks.com or request a demo.

About the authors

Steven Bacci is a Principal Solution Architect within Global Financial Services at AWS, with over 25 years experience in financial services firms, principally in software engineering for Capital Markets. More recently Steven has been focused on blockchain and digital assets.

Forrest Colyer is a Sr. Specialist Solutions Architect focused on Web3 and decentralized technologies at AWS. He provides deep technical guidance to customers across industries as they build workloads that rely on technologies like blockchain, and also works to cultivate partnerships with ISVs in the Web3 space.

Mar Anthony Go is the Director of R&D, Tokenization Solutions at Fireblocks, where he focuses on implementing tokenization strategies and solutions for businesses. He leads a team that develops custom smart contract implementations using Fireblocks’s infrastructure and is involved in the full delivery process, from defining product requirements to overseeing development and release cycles.

Karin Susan is a Business Analyst within the Financial Markets team at Fireblocks, currently supporting tokenization initiatives at Fireblocks with a keen focus on bespoke solutions, product development, and strategic partnerships.

Francois Schonken is the Senior Director of Tokenization at Fireblocks. He is responsible for creating future-proof, bespoke tokenization solutions for Fireblocks customers looking to leverage blockchain to enable both the tokenization of financial and non-financial assets.

Adam Hart is a Director in the Corporate Strategy team at Fireblocks, focused on developing joint Go-To-Market strategies and value propositions with our Cloud and Consulting partners that best address the needs of our respective client bases. Adam is also responsible for delivering Fireblocks’ Cloud Marketplace roadmap and for driving business growth through this channel.