[Xangle RWA Series] Wallet Infrastructure

 

1. Introduction

2. Customer Wallet Classification

3. Enterprise Wallet Classification

4. Major Wallet Infrastructure Vendors

5. Comparing RWA Wallet Vendors

6. Conclusion

 

 

1. Introduction

The previous report examined who holds digital assets and how the keys and approval rights required to transfer them are controlled. Yet secure custody and a key management system (KMS) alone do not allow investors to use a product or companies to carry out on-chain operations. Users need a way to access assets and approve transactions, while companies must operate customer assets and their own assets separately according to purpose. Wallets provide the interface that connects this foundation to actual services and business processes.

The term wallet can give the impression that tokens are stored inside a wallet application. In reality, tokens are recorded on the blockchain, not held in the wallet. A wallet is a tool that lets users access their blockchain accounts, check balances, and approve transactions. It is similar to how a banking app displays account information without containing the money itself. The difference is that blockchain transactions are approved with cryptographic keys, which may be managed directly by the user or on the user's behalf by a platform or external custodian.

Investors may interact with wallets in very different ways even when using similar RWA products. Ondo's OUSG uses a structure in which onboarded investors connect their own external wallets and purchase the asset. Franklin Templeton's Benji, by contrast, does not require investors to prepare a separate wallet. Individuals sign up through the Benji Investments app, while institutions use the Benji institutional web portal, and the platform provides an investor wallet as part of the service. Investors hold shares and request purchases and redemptions within the app, and tokens can only be transferred to and from addresses that have passed identity verification and been added to the allowlist.

From a corporate perspective, it is also difficult to operate every function through a single wallet. Assets managed on behalf of customers must first be separated from the company's proprietary assets, and the company must be able to verify each customer's rights and the amount to be returned. For assets owned directly by the company, the choice is whether to retain control of the keys or entrust them to an external custodian. Direct control gives the company discretion over transaction speed and the scope of automation, but it also leaves the company responsible for key management and internal controls. External custody transfers safekeeping responsibility to a specialist institution, but withdrawals and supported assets are then subject to the custodian's policies. Administrative powers that affect the entire product, such as token issuance, freezing, or contract changes, are also difficult to place in the same wallet used for ordinary transfers.

This report therefore examines wallets from two perspectives: the user and the enterprise. One conclusion repeatedly emerges from both. The type of wallet visible on screen does not reveal who actually controls the assets, and many functions required for RWA products sit outside the wallet itself. Selecting wallet infrastructure and building a product structure that satisfies regulatory requirements are therefore separate tasks. The purpose of this report is to identify where the boundary between them lies.

The report first classifies customer wallets according to who provides the wallet, separating external wallet connections from service-provided wallets. Service-provided wallets are then divided into user-controlled and provider-controlled models according to who controls signing authority. Enterprise wallets are classified by asset ownership into customer asset service wallets and wallets for corporate asset operations. Wallets for corporate asset operations are further divided by the location of key control into third-party custody and self-custody. These are not mutually exclusive wallet types. They describe different layers: the access model visible to the user and the enterprise's internal operating structure.

The report then introduces representative infrastructure in each category. It covers Kresus, Privy, and Dynamic for customer wallet infrastructure, and Anchorage Digital, BitGo, and Fireblocks for enterprise wallet infrastructure. Finally, it compares vendors in each category across four criteria: security and regulation, supported networks and assets, token and RWA functionality, and product delivery model.

 

2. Customer Wallet Classification

Users do not necessarily need to prepare a separate blockchain wallet before accessing an RWA service. They may connect a wallet they already use, or the service may provide a wallet or wallet account during sign-up.

Customer wallets can therefore first be divided according to who provides the wallet: the external wallet connection model and the service-provided wallet model. Under the external wallet connection model, users connect an existing wallet obtained outside the service. Under the service-provided wallet model, users do not prepare a separate external wallet. Instead, the service provides the wallet environment used within its application. Service-provided wallets can then be divided into user-controlled and provider-controlled models according to who controls signing authority.

Control in this chapter refers to the technical authority to approve and execute transactions. The legal status required to hold and manage customer assets, which is the question of custody, is addressed together with asset ownership in Chapter 3. The fact that a provider signs on behalf of a user does not by itself mean that the provider holds a custody license, and the reverse is also true.

2-1. External Wallet Connection Model

The external wallet connection model allows users to connect a blockchain wallet they already own to an RWA service. When an individual uses a wallet such as MetaMask, the service sends a connection request through its interface and the user approves it in the wallet. Transaction requests required for purchases or transfers are then passed to the connected wallet. Ondo's OUSG, mentioned earlier, uses this model. Once an onboarded investor connects a wallet and registers it as an approved address, subsequent purchases and transfers are conducted through that address.

A common standard is needed to connect multiple external wallets to one service without requiring the service to implement a different connection method for each wallet. Standards such as WalletConnect are widely used to establish a session between the service and an external wallet and relay signature or transaction requests to the user's wallet. Wallet infrastructure providers also package these connection functions into SDKs. In either case, the service provider can support multiple wallets without building its connection layer around one specific wallet.

The defining feature of the external wallet connection model is not who manages the keys, but that the user brings a wallet obtained outside the service. It may be a self-managed wallet such as MetaMask, an enterprise wallet operated by an institution, or a wallet managed by an external custodian. Individuals sign transactions directly from personal wallets, while institutional or custodial wallets may execute transactions only after internal organizational approvals or custodian procedures.

This model allows one wallet to be used continuously across multiple on-chain services. When an RWA product permits external transfers or on-chain use, investors can move their tokens to another approved address or connect them to other services. Companies that have already established an institutional wallet framework also do not need to create a new wallet for every product they adopt.

The trade-off is a higher entry barrier because users must prepare a wallet before joining the service. Individual users must understand wallet installation, key storage, network selection, and transaction signing. They may also need to fund network fees themselves. If they sign an incorrect transaction or lose access to the wallet, the problem cannot usually be resolved by simply resetting a password as it can in conventional financial services.

Regulated RWA products that restrict investor eligibility or permitted recipients also require a process linking wallet addresses to investor identities. Even after identity verification, a new address that has not been registered with the platform is not automatically approved. Depending on the product's terms, the new address may need to be registered again. A transfer can also be rejected even after it is signed if the recipient address is not eligible to hold the product.

2-2. Service-Provided Wallet Model

Under the service-provided wallet model, the service supplies a wallet or wallet account during sign-up or onboarding instead of requiring the user to obtain one externally. Users can view assets and transact by signing in with familiar methods such as email or social accounts, without installing a separate wallet application.

Service registration and wallet creation become part of a single flow. The platform can provide a wallet to a user who has completed identity verification and simultaneously register that address as an approved investor address. This also reduces errors such as connecting a wallet on the wrong network or entering an incorrect address.

The wallet and transaction flow can be embedded within the service interface. By bundling several transaction steps together or paying network fees on the user's behalf, the service can allow customers to access an RWA product with little awareness of the underlying blockchain. This makes the model well suited to onboarding customers accustomed to conventional financial applications.

The fact that the service provides the wallet does not by itself determine who controls the assets. The wallet may require the user to provide final approval for each transaction, or it may allow the service provider or an external custodian to execute transactions on the user's behalf. Service-provided wallets are therefore divided into user-controlled and provider-controlled models.

(1) User-Controlled

In a user-controlled model, the service creates the wallet, but the user retains final authority to move the assets. The user approves transactions directly within the service, and the platform cannot transfer assets at its own discretion without the user's permission.

User control does not mean that the user must manually process every transaction. For recurring purchases or repeated asset management, the user may delegate authority to the platform to execute certain transactions within a predefined scope. The platform's authority must remain limited to the assets, amounts, periods, and counterparties specified by the user, and the user must be able to modify or revoke it. If the delegation is excessively broad or cannot be revoked, the structure is provider-controlled in substance even if it is described as user-controlled.

The user-controlled model combines a simpler onboarding process than external wallet connections with continued user control over assets. Users can join the service without installing a separate wallet application or entering a seed phrase, while the service can combine identity verification, wallet creation, and approved address registration into one flow.

The service provider, however, cannot execute transactions beyond the scope authorized by the user. If the user revokes delegated authority or loses the means of accessing the wallet, recurring transactions, redemptions, and asset transfers may be interrupted. The provider also has limited ability to act alone in situations where immediate user approval cannot be expected, including inheritance, disputes, and legal orders. When users can export their wallets, they may also transact directly outside the service, making it difficult to keep every activity within the platform's approval process.

(2) Provider-Controlled

In a provider-controlled model, the service provides a wallet or wallet account, while the service provider or a designated external custodian manages the actual signing authority. Users log in to a platform account as they would in a conventional financial service and submit requests to purchase, transfer, or redeem assets. The party controlling the wallet then executes the blockchain transaction according to internal policies.

Users do not need to store keys directly or sign each transaction. More importantly, the service provider or custodian can assume responsibility for transaction execution and exception handling as the operator of the customer account. When a user requests a purchase or redemption, the provider completes it under established procedures. If the user loses access credentials, account access can be restored after identity verification. The provider can also handle inheritance, disputes, legal freezes, and other situations in which obtaining the user's direct signature is difficult, following predefined procedures.

In return, users depend on the procedures of the service provider or custodian whenever assets are moved. Key questions include whether assets can be transferred to an external wallet, how long withdrawal approval takes, and how assets would be returned if the service shuts down or the provider becomes insolvent. Even when each user has a distinct blockchain address, the user cannot transact independently outside the platform if the user does not hold signing authority.

The wallet type visible to the user does not reveal how the company actually manages customer assets. Under an external wallet connection model, the connected wallet may still be managed by an external custodian. Under a provider-controlled model, the company may assign a separate address to each user or pool multiple customers' assets in one wallet and distinguish their balances in an internal ledger. In particular, the customer interface does not show whether the service provider controls the signing authority directly or delegates it to an external custodian. The next chapter examines who controls customer and corporate assets and how those assets are operated, from the enterprise perspective.

 

3. Enterprise Wallet Classification

Customer wallets show how customers access a service, while enterprise wallets show how the company operates assets behind that interface. Assets belonging to customers and assets owned by the company must be considered separately. The two differ not only in management purpose, but also in the starting point for determining the wallet structure.

Enterprise wallets can therefore be divided by asset ownership into customer asset service wallets and wallets for corporate asset operations. For customer asset service wallets, the central question is whether the company can clearly identify whose assets they are and return them. For wallets for corporate asset operations, the question is whether the company controls the keys directly or entrusts them to an external custodian.

Customer asset service wallets begin with the question of who controls asset transfer authority on behalf of customers. If the service provider directly controls customer assets, custody licensing or institutional status becomes relevant. If an external custodian controls them, the roles and responsibilities of the custodian and the service provider must be distinguished. The previous report examined these issues in detail, including custodial status, key management, customer-level segregation, and omnibus structures. Rather than repeating that analysis, this report briefly explains how custody structures for customer assets connect to wallet infrastructure.

This classification is separate from the customer wallet types discussed earlier. Even a service that lets customers connect external wallets may need its own wallet to process fees and settlement. Conversely, a service that provides provider-controlled wallets to customers must operate both customer asset service wallets and wallets for corporate asset operations.

3-1. Customer Asset Service Wallets

A customer asset service wallet is operated by a company to safeguard assets or process transactions on behalf of customers. When users access a provider-controlled wallet or purchase assets through a platform account, the actual tokens may be managed within this wallet structure.

Customer assets may be held in separate wallets assigned to each customer, or multiple customers' assets may be pooled in one wallet and distinguished by customer in an internal ledger. The first approach makes customer-level assets easier to identify on-chain, but increases the number of addresses that must be operated. The second improves the efficiency of fund movements and fee management, but requires reconciliation to ensure that customer balances in the internal ledger always match the actual on-chain balance.

Regardless of the structure selected, customer assets must be separated from corporate assets. Separation must exist not only in the system interface, but also in the actual wallets and ledgers so that asset ownership can be verified. Procedures are also needed to determine each customer's holdings and transfer them to another wallet or custodian even if the service experiences an outage or ceases operations.

When a wallet infrastructure vendor is used, the company must distinguish whether the vendor actually takes custody of the assets or only provides wallet creation and transaction-signing technology. Even if a technology vendor provides customer-specific wallets and an internal ledger, the legal segregation of customer assets and responsibility for their return depend on the contractual structure between the service operator and the actual custodian.

This distinction remains relevant even when funds are held only temporarily. Subscription or redemption proceeds may pass through the company's settlement flow, but if they belong to customers, they should be treated as customer assets rather than corporate assets. Which wallet performs the payment function and who legally owns the assets are separate questions.

3-2. Wallets for Corporate Asset Operations

Wallets for corporate asset operations manage digital assets that the company owns and uses for business purposes. These include company-held stablecoins and crypto assets, operational reserves, and assets used to pay network fees.

Not all corporate assets serve the same function. Treasury assets held for long periods, funds repeatedly used for payments and settlement, and operational assets used to call smart contracts differ in transaction frequency, external exposure, and the potential impact of an incident. Companies also hold administrative powers that may involve little or no asset balance but can affect the entire product, including token issuance and burning, investor address registration, transfer restrictions and freezes, and contract upgrades.

These differences explain why wallets should be separated, but they do not determine the wallet structure itself. The structure is determined by where the key control required for each asset should reside. Large treasury positions that transact infrequently may be better entrusted to a specialist custodian. Assets used to pay network fees, call contracts, or automate bulk payments cannot easily depend on an external institution's withdrawal process for every transaction. Administrative powers should likewise remain under the control of the product operator, while being divided so that no single person can exercise them alone.

Wallets for corporate asset operations are therefore divided according to who controls the keys: third-party custody and self-custody. In practice, companies often use both approaches for different types of assets rather than choosing only one.

(1) Third-Party Custody

Under third-party custody, an external custodian manages the keys to assets owned by the company, while the company acts as the authorized account holder and instructs deposits, withdrawals, and asset operations. The assets are held within the custodian's wallet structure, and company employees request transactions through the custodian's interface or API.

Companies choose this structure because safekeeping is difficult to perform well in-house. Key generation and backup, physical security, access management, and incident response require dedicated personnel and infrastructure. Using a licensed custodian transfers this burden while also providing an institutional basis for audits, insurance, and asset segregation. For regulated institutions required to hold assets with a qualified custodian, this may be a compliance requirement rather than a discretionary choice.

The range of activities available to the company is constrained by the custodian's policies. Supported networks and assets, withdrawal times and approval procedures, and the ability to call arbitrary smart contracts all vary by custodian. Even when contract calls are supported, they are often limited to protocols on an allowlist.

The custodian itself also becomes a new source of risk. Due diligence must cover its license and legal status, whether customer assets are separated from the custodian's proprietary assets, how assets are treated in insolvency, and whether assets can be transferred to another institution if service is suspended or the contract ends.

(2) Self-Custody

Under self-custody, the company directly controls the keys to its assets. It may manage keys on its own infrastructure or deploy key management technology while retaining signing authority internally. In either case, final authority to approve transactions remains within the company.

Direct control does not mean that a single employee holds the key. The central question is how control is divided. The person requesting a transaction should be separated from the person approving it. Transactions above a certain amount or to a new recipient can require multiple approvals, and withdrawals can be restricted to pre-registered addresses. For smart contract interactions, policies should be able to evaluate the target contract, the function being called, and the addresses and amounts passed into that function. Another widely used approach divides key material among multiple parties so that a signature can be completed only when the required number of parties approve.

This model is suited to operations that require speed and automation, including recurring payments and settlement, contract calls, and protocol deposits. A company can receive payment instructions from its order or accounting systems, generate transactions, and feed the completed results back into its internal ledger. It is also natural for the company operating a product to retain administrative powers such as token issuance and freezing, investor list changes, and contract upgrades, while applying distinct approval procedures to each power.

Responsibility for failures of control, however, also remains with the company. It must design recovery procedures for lost or compromised keys, revoke permissions when employees leave or organizational roles change, record approval histories, and support audits. As automation expands, a single incorrect condition can trigger transactions at scale. The company therefore needs a process to verify which assets will move, where they will go, and what new permissions will be granted before execution.

The two models are not mutually exclusive. A common structure holds reserves with a custodian while using a directly controlled wallet for routine settlement and contract transactions, moving funds from the custody account to the operating wallet only as needed. Transfers between the two domains then become a separate category of transaction requiring approval.

This chapter has outlined how users interact with wallets and how companies operate assets. The next chapter introduces wallet infrastructure vendors that implement these structures, separating customer wallet infrastructure from enterprise wallet infrastructure.

 

4. Major Wallet Infrastructure Vendors

The previous chapters examined how users interact with wallets and why companies need to control assets in different ways. Building an actual service requires either developing these structures in-house or selecting wallet infrastructure that provides the necessary functions.

Wallet infrastructure vendors do not all solve the same problem. Customer wallet infrastructure creates the interface through which customers access a service, while enterprise wallet infrastructure provides the procedures through which companies control assets and on-chain permissions. This chapter introduces representative vendors in each category without repeating the detailed analysis of custody licensing or MPC and HSM architectures covered in the previous report.

4-1. Structure of the Wallet Infrastructure Market

The wallet infrastructure market follows the same axes as the classification in the previous chapter. Customer wallet infrastructure supports either connecting a customer's existing wallet or providing a wallet within the service. Enterprise wallet infrastructure supports either entrusting assets to an external custodian or retaining direct control.

A notable feature of this market is how extensively it has been reshaped over the past two years. Stripe announced its acquisition of embedded wallet infrastructure provider Privy on June 11, 2025, and Privy continues to operate as an independent product under Stripe. On June 2 of the same year, Consensys acquired Web3Auth and integrated it into MetaMask. Fireblocks then acquired wallet development platform Dynamic on October 23. Transaction values were not disclosed for any of the three deals. In less than a year, many embedded wallet vendors that developers had chosen for their independence were brought under major payments and infrastructure companies.

This restructuring adds a new item to vendor due diligence. Even if a product is not discontinued, its roadmap follows the strategy of its parent company. A company adopting wallet infrastructure must therefore assess whether its own direction remains aligned with that of the vendor's parent.

Another trend is the blurring boundary between the two categories. Fireblocks described the Dynamic acquisition as creating a stack spanning everything from custody to consumer-facing wallets, while Anchorage Digital operates the Porto self-custody wallet separately from its custody services. Vendors that began with institutional custody are expanding into customer wallets, while customer wallet providers are moving toward institutional infrastructure. Yet even when one vendor serves both categories, the control structures for customer assets and corporate assets do not merge into one.

4-2. Customer Wallet Infrastructure

Customer wallet infrastructure creates the interface between an RWA service and its customers. The appropriate choice depends on whether the company wants to distribute a finished wallet under its own brand, assemble wallet functions itself, or support both external wallet connections and service-provided wallets.

The following three vendors were selected not by market share, but to illustrate three distinct implementation models: a white-label provider that delivers a complete wallet product (Kresus), an SDK and API provider that supplies wallet functions as modular components (Privy), and an integrated SDK that combines external wallet connections with service-provided wallets (Dynamic).

(1) Kresus

Kresus provides white-label wallet infrastructure that allows companies to distribute wallets under their own brands. It supports an embedded model integrated into an existing product, a web-based portal, and a standalone application. Deployments can use user-controlled, provider-controlled, or hybrid structures. Under the classification in the previous chapter, it is a product that delivers the service-provided wallet model as a complete package.

Its product scope extends beyond wallets. Kresus also presents the Kite RWA tokenization platform and stablecoin payment and settlement workflows. Kite is described as infrastructure for issuing and managing real-world assets and processing payments across institutional networks and EVM chains.

Kresus also has a connection to the Korean market. At Abu Dhabi Finance Week 2025 in December 2025, Kresus signed a memorandum of understanding with Hanwha Investment & Securities to build digital asset infrastructure. The announced scope covered digital wallets and tokenization, blockchain technology development, and personnel exchanges. No specific implementation has yet been disclosed, but a structure in which a wallet infrastructure vendor also participates as a tokenization partner is one that Korean financial institutions may encounter in practice.

Kresus's public materials, however, focus on product configuration and deployment models. Its developer documentation does not provide detailed information on implementation coverage by network or the precise scope of its security certifications. The party controlling the wallet, the recovery structure, and data portability terms should therefore be verified through direct due diligence rather than public materials alone.

(2) Privy

Privy is embedded wallet infrastructure that allows login and wallet creation to be integrated into a service. It can create wallets for users while leaving control with them, operate groups of enterprise-controlled wallets, and assign approval authority at the individual wallet level. Unlike Kresus, which supplies a finished wallet, Privy is modular infrastructure that lets the company design the interface and flow itself.

Its key management architecture combines a trusted execution environment (TEE) with key splitting. Low-level APIs give developers direct access to session signers and policy controls. The policy engine can restrict permitted contracts and recipients, maximum transfer amounts, and contract call data. Transactions can also require multi-factor authentication or multiple approvals. Gas sponsorship is available as a standard feature.

The depth of its documentation is an advantage for pre-deployment assessment. However, investor eligibility checks, transfer agency, and product-specific transfer restrictions required for RWA products are not completed by Privy itself. They must be connected through token contracts and external systems.

(3) Dynamic

Dynamic positions itself as a single SDK that combines external wallet connections, embedded wallets, and multichain connectivity. The same SDK handles embedded wallets, social login, and connections to numerous external wallets, while email, SMS, and passkeys support onboarding. Its distinction from the other two vendors is that it supports both the external wallet connection model and the service-provided wallet model within one product.

Its embedded wallets leave control with the user. Dynamic uses TSS-MPC to divide key shares between the user's device and its server, with a default 2-of-2 configuration that can be adjusted to 2-of-3. Users can export their wallets and move them to another provider or storage environment. Documented key portability is a relevant consideration when assessing service discontinuation or vendor replacement.

Ondo, introduced in Chapter 1, is a notable RWA use case. Ondo Finance uses Dynamic across products including OUSG to let users connect existing wallets. This is a typical example of an external wallet connection service relying on infrastructure rather than building the connection layer itself.

4-3. Enterprise Wallet Infrastructure

Enterprise wallet infrastructure corresponds to the two branches described in Section 3-2. The vendor set differs depending on whether the company entrusts assets to an external custodian or retains direct control of the keys while implementing control procedures through infrastructure. The following three vendors were again selected not by scale, but by their position on this spectrum: a regulated custodian (Anchorage Digital), a provider offering both models within one corporate group (BitGo), and a platform that implements direct control through infrastructure (Fireblocks).

(1) Anchorage Digital

Anchorage Digital is a representative example of third-party custody. It received a national bank charter from the U.S. Office of the Comptroller of the Currency (OCC), the first granted to a crypto company, and also holds a license from the Monetary Authority of Singapore (MAS) and a New York BitLicense. Its custody service is based on asset segregation and bankruptcy remoteness, and provides round-the-clock transaction authorization through biometric approvals.

From an RWA perspective, the relevant point is the nature of the supported assets. Anchorage's charter permits custody of a broad range of digital assets, including tokenized securities and stablecoins. A recurring structure can be seen in cases such as Anchorage providing institutional custody for Mexican government bond tokens (CETES) issued by Etherfuse on Stellar: the issuer tokenizes the asset, a public or permissioned chain handles settlement, and a regulated custodian holds the tokens on behalf of investors. On June 22, 2026, Anchorage also introduced infrastructure that allows banks to issue and manage tokenized deposits. Under the proposed division of responsibilities, Anchorage provides blockchain infrastructure, wallet management, and smart contracts, while the bank retains the customer relationship and front end.

For enterprises, the key consideration is the scope of control. Operations must be designed within the custodian's approval framework, so the supported asset and network lists, the ability to call arbitrary contracts, and whether withdrawal and approval times match the company's settlement cycle must all be verified before contracting.

(2) BitGo

BitGo is distinguished by offering regulated custody and direct control within the same corporate group. Custodial wallets are provided through regulated trust entities including BitGo Bank & Trust, a national trust bank, BitGo New York Trust Company, and its European and Swiss entities. The service includes detailed audit trails, reporting tools, and policy enforcement. BitGo also offers configurations in which self-controlled wallets and regulated custody, as well as hot and cold wallets, can be deployed independently or together. Technology and software are handled by a separate entity responsible for non-custodial SaaS products.

In its self-controlled cold wallet model, the customer holds two of three keys and sends transactions that were partially signed offline to a co-signing platform. This can be viewed as a product implementation of the distributed control structure described in Section 3-2.

BitGo listed on the New York Stock Exchange under the ticker BTGO on January 22, 2026. According to its listing filing, the platform had approximately $104 billion in assets under custody as of September 30, 2025. The listing increases the amount of financial information available publicly, which can be useful in custodian due diligence.

(3) Fireblocks

Fireblocks implements self-custody through infrastructure. It combines MPC with hardware isolation to distribute key material across multiple parties, emphasizing that the divided structure prevents Fireblocks from moving customer assets on its own. Asset control remains with the enterprise, while the vendor provides the layer that executes approval procedures and policies.

The platform is designed to combine custody, treasury operations, policy controls, and network connectivity in one management interface. For tokenization, it treats large-scale issuance and burning, the integrity of investor allowlists, and smart contract governance as distinct security requirements. For stablecoin issuers, it proposes enforcing reserve account controls and issuance authority policies at the hardware level rather than only in the application. As of an announcement in February 2026, Fireblocks supported 150 public blockchains, 46 of which were added during 2025. Its integrations also include institutional networks.

Fireblocks also has a custody business. Fireblocks Trust Company operates as a qualified custodian regulated by the New York State Department of Financial Services (NYDFS), while the platform includes compliance functions such as AML screening, Travel Rule support, and a policy engine. Companies must therefore verify at the contract level which legal entity they are dealing with and where asset control actually resides, rather than relying on the product name.

Its nature as a managed platform also creates a burden. As policies, wallet structures, and treasury procedures become deeply integrated into the platform, the vendor becomes part of the company's operating system rather than a single supplier. The ability to migrate wallets and approval records, and to access assets independently during a contract termination or service outage, is therefore subject to the same due diligence requirements outlined for self-custody in Section 3-2.

Viewed side by side, the most immediate differences among the three vendors lie in their contractual structures rather than their feature lists. Even when using products from the same company, the legal treatment of assets and responsibility in an incident depend on the legal entity with which the customer contracts. The next chapter compares the two vendor categories using a common set of criteria.

 

5. Comparing RWA Wallet Vendors

The previous chapter examined how Kresus, Privy, and Dynamic create customer interfaces, and how Anchorage Digital, BitGo, and Fireblocks support enterprise asset control. Rather than introducing each vendor again, this chapter compares them across four criteria: security and regulation, supported networks and assets, token and RWA functionality, and product delivery model.

Customer wallet infrastructure and enterprise wallet infrastructure solve different problems, so they are not combined into one table. Even under the same criteria, customer experience and the transfer of control shape the analysis for customer wallets, while the legal treatment of assets and internal controls shape it for enterprise wallets.

5-1. Comparison Criteria

(1) Security and Regulation

This criterion varies not only between the two categories but also by the contractual model used for enterprise wallet infrastructure. For customer wallet infrastructure and self-custody technology platforms, the question is whether their operational controls have been independently validated. For third-party custody services, the question is whether the provider has the legal status required to hold assets. Applying a single yardstick would mix fundamentally different considerations, so the comparison tables below distinguish certifications from regulatory authorization.

For customer wallet infrastructure, the relevant evidence is certification. SOC 2 is an assurance framework under the American Institute of Certified Public Accountants' Trust Services Criteria, in which an independent auditor reviews controls related to security, availability, processing integrity, confidentiality, and privacy. A Type II report assesses whether those controls operated effectively over a period of time. ISO/IEC 27001 is an international standard specifying requirements for an information security management system. Both assess how a company operates its systems. Neither addresses the legal segregation of customer assets or their treatment in insolvency.

Enterprise wallet infrastructure requires separate assessment of self-custody technology platforms and third-party custodians. For self-custody platforms, technical certifications and the design of key controls and approval workflows are central. Third-party custodians operating under a national bank or trust company charter, or a state-level license, are instead subject to regulatory requirements for asset segregation, bankruptcy remoteness, and reporting. When a regulated institution is required to use a qualified custodian, this status, rather than the vendor's technical quality, determines whether adoption is possible. A technology platform may hold certifications while a separate legal entity holds the custody status, so companies must also verify whether their contractual counterparty is the technology provider or the custodian.

(2) Supported Networks and Assets

Supported networks refer to the blockchains on which a wallet can create addresses and execute transactions. The number of supported chains alone does not define the functional scope. On one network, a vendor may support wallet creation, transaction submission, policy enforcement, and gas sponsorship, while on another it may support only address generation and signing.

Assets must be considered alongside networks because custodians and technology infrastructure operate differently. Technology infrastructure can generally handle a new token if it supports arbitrary contract calls on the relevant chain. Custodians, by contrast, review assets individually before adding them to a supported list. Holding a specific RWA token therefore first requires confirmation that the token has been approved. Korean institutions must additionally consider support for permissioned networks.

(3) Token and RWA Functionality

Institutions pursuing real-world asset tokenization need functionality that manages not only token issuance and transfers, but also the rights attached to the underlying assets and the applicable regulatory requirements. Typical requirements include verifying whether an investor is eligible to hold the product, restricting transfers to approved investors, and freezing or recovering tokens in response to legal orders or errors. Major actions such as issuance, burning, and changes to the investor registry also require approval procedures distinct from ordinary transfers.

Many conventional stablecoins and fund tokens are issued under ERC-20 or a compatible structure. ERC-20 is the basic interface that standardizes balance queries, transfers, and third-party spending approvals for fungible tokens on Ethereum. It does not define functions required for regulated financial products, such as investor eligibility checks, transfer restrictions, freezes, or recovery. Issuers can add these through separate smart contract logic or use a regulated token standard such as ERC-3643, which combines on-chain identity, eligibility verification, and compliance rules.

Claims that a wallet supports a specific token standard should nevertheless be interpreted carefully. Any wallet capable of calling EVM smart contracts can technically execute functions on an ERC-3643 token. The practical distinction lies elsewhere: whether approvers can clearly see the substance of issuance, burning, freezing, or recovery transactions; whether each action can have its own approval policy; and whether the wallet can connect to investor registries, KYC systems, and transfer agency systems.

(4) Product Delivery Model

Even when the wallet functionality is the same, the delivery model determines how much the enterprise must build itself. An SDK is a package of vendor-developed code integrated into the company's application. It often includes user-facing components for login, wallet creation, and signature requests. An API sends requests to the vendor's servers. The enterprise must build the interface itself, but can automate processes that do not pass through a user screen, such as recurring purchases, bulk payments, or address registration in the back office. The two are not mutually exclusive. Vendors generally provide both, with the interface implemented through an SDK and policies and signing managed through APIs.

A white-label model distributes a finished wallet under the company's name and design. It enables a faster launch with little to build, but limits the interface and feature set to the framework defined by the vendor. Managed platforms and custody agreements are different in nature. The first three models add functions to a product built by the company, while managed platforms and custody agreements bring the company's operations into systems operated by the vendor. The review therefore focuses less on development scope and more on contractual terms, approval procedures, and migration arrangements at termination.

5-2. Customer Wallet Infrastructure Comparison

All three vendors help companies provide wallets to customers, but they begin from different points. Kresus provides a finished wallet product, Privy supplies modular wallet functions, and Dynamic combines external wallet connections with embedded wallets.

The security comparison first reveals differences in the amount of public information available. Privy renews its SOC 2 Type II report annually, undergoes quarterly external assessments by firms including Cure53 and Zellic, and makes architecture documents and assessment summaries available through its trust center for security review. Dynamic also holds SOC 2 Type II, conducts regular external assessments, and runs a public bug bounty program. Kresus, by contrast, publishes materials focused on product configuration and deployment models, so the scope of its certifications must be verified through direct due diligence.

The three vendors also show different strengths across networks and assets. Dynamic handles embedded wallets, social login, and numerous external wallet connections through one SDK, making it suitable for services that need to accommodate a broad range of wallets already held by customers. Privy has deeper functionality around EVM and Solana. Separately from the chains supported by its consumer wallet, Kresus presents Kite as infrastructure for handling real-world assets across institutional networks and EVM chains. For Korean institutions evaluating permissioned networks, Kresus's provision of wallet and tokenization infrastructure to the Canton ecosystem may offer a practical point of entry.

The largest differences appear in RWA functionality. Privy and Dynamic are general-purpose infrastructure for configuring wallets and transactions, so investor eligibility, transfer restrictions, and transfer agency must be handled through token contracts and external systems. Dynamic states this boundary explicitly. It does not directly perform identity verification, AML screening, or transaction monitoring. Instead, it provides infrastructure controls such as screening integrations, policy rules, and audit trails, while the actual review is conducted by the compliance provider selected by the enterprise. Kresus extends its product scope beyond wallets by presenting Kite as a platform for issuing, managing, and settling tokens backed by real-world assets. Kite is nevertheless a separate product from the white-label wallet, and its supported standards are not specified in detail in public materials.

Placed side by side, the three vendors' common limitations are more immediately visible than their differences. Functions that make an RWA product distinct, including investor eligibility checks, transfer restrictions, and registry management, remain outside the wallet regardless of the vendor selected. Wallet infrastructure creates the path through which customers access an asset, but it does not determine who is allowed to receive that asset. Vendor comparison alone cannot resolve this issue. Institutions must first define the token standard, the party responsible for registry management, and the eligibility verification process, then identify the integration points required from wallet infrastructure.

5-3. Enterprise Wallet and Custody Infrastructure Comparison

The three vendors occupy different positions in enterprise wallet custody. Anchorage Digital represents third-party custody, while Fireblocks and BitGo offer both third-party and self-custody models under the same corporate group or brand.

On the security and regulatory axis, the scope of authorization differs. Anchorage Digital holds an OCC national bank charter, a MAS license, and a New York BitLicense, giving it a regulatory foundation across multiple jurisdictions. BitGo provides custody through regulated trust entities including a national trust bank, a New York trust company, and European and Swiss entities, while a separate entity handles technology and software. Fireblocks is primarily a technology platform, with custody provided by a trust company supervised by New York State that operates as a qualified custodian. Because two of the three companies offer both models, the relevant question is not the number of licenses or the vendor's reputation. It is whether the entity contracting with the institution is the technology provider or the custodian.

Networks and assets are approached at different levels. Anchorage and BitGo assess individual assets before adding them to supported lists. BitGo emphasizes the breadth of this coverage, stating that it supported 186 of the top 250 assets by market capitalization as of the first quarter of 2026, based on its own data. Fireblocks approaches support at the chain level and covers 150 public blockchains. To handle a specific RWA token, adoption depends on whether the token itself is supported at Anchorage or BitGo, and whether Fireblocks supports the chain on which the token is issued.

The vendors also differ in the part of the token and RWA stack they choose to address. Anchorage focuses on custody and settlement. BitGo has integrated Polymesh, a blockchain dedicated to regulated assets, into its custody offering. Through its acquisition of Brassica, it also owns an SEC-registered transfer agent and therefore extends into the registry layer that the previous section identified as sitting outside the wallet. Fireblocks focuses on executing powers such as issuance and burning and protecting allowlist integrity, and enforces issuance authority policies at the hardware level. Fireblocks is the only one of the three that directly addresses the administrative authority controls described in Section 3-2. Institutions choosing either of the others must design those controls themselves.

Differences in delivery models lead to different forms of dependency after implementation. Anchorage's custody agreement minimizes internal build requirements, but limits operations to the scope of the contract. BitGo's 2-of-3 co-signing model is an intermediate structure in which the customer holds two of three keys and shares control. Integrating policies and treasury processes into a platform such as Fireblocks improves efficiency, but also makes the vendor part of the enterprise's operating system. Since these approaches can coexist even within one corporate group, due diligence is better organized at the wallet level rather than the vendor level.

The three vendors are not simply competing to provide the same function. The appropriate choice depends on how much control the enterprise intends to retain. Rather than beginning with a ranking of vendors, an institution should first determine whether the assets it handles are subject to statutory segregation requirements, whether contract calls and automation are essential to operations, and how administrative powers should be divided. It can then evaluate the vendors that correspond to those decisions.

 

6. Conclusion

A digital asset wallet is neither a repository that contains tokens nor merely a transfer interface. It is an interface for accessing assets recorded on a blockchain and approving transactions, as well as service infrastructure that connects the user experience with an enterprise's internal controls.

These two layers do not necessarily match what appears on screen. A simple login may lead to a user-controlled wallet or to an account for which the service provider signs transactions. The customer interface also does not reveal whether the service provider itself or an external institution holds the keys in a provider-controlled service. This is why the controlling party and recovery path should be examined before the feature list when evaluating a wallet.

Vendor selection follows the same logic. The task is not to choose the infrastructure with the most features, but to decide which wallets will be operated for which purposes and then find infrastructure suited to that structure. The review items differ by category. Customer wallet infrastructure providers are technology vendors, so security certifications, documentation quality, and key portability matter. For enterprise wallet infrastructure, custody authorization, asset segregation, and whether the contractual counterparty is the technology provider or the custodian come first. Certifications and regulatory authorization do not substitute for one another. Market restructuring over the past two years adds another consideration. Because product roadmaps follow parent company strategies, long-term agreements must assess ownership structures and migration options alongside product functionality.

The comparison also shows that many functions required for RWA products remain outside the wallet. Investor eligibility checks, transfer restrictions, investor registries, and transfer agency are not completed by wallet vendors. They must be implemented through token contracts and external systems. Some vendors provide tokenization platforms alongside their wallet products, but these are still separate components. Selecting wallet infrastructure and designing a product structure that satisfies regulatory requirements are tasks that must be addressed in the proper sequence.

This leads to the questions institutions must examine going forward. Can users still access their assets after the service shuts down? Are customer and corporate assets separated in the actual wallets and ledgers? Are high-impact powers such as token issuance and freezing appropriately segregated? As the RWA market expands, wallet competition will move beyond key security toward how naturally infrastructure connects regulatory requirements, user experience, and enterprise internal controls.