Securitize, with over $3B in tokenized assets, is the standout front runner and the leader by TVL among RWA tokenization platforms, and it is well known in the community for tokenizing BlackRock’s BUIDL, Apollo’s ACRED, and VanEck’s VBILL, among others.
When tokenizing RWAs, designing the smart contract structure of how tokenized securities operate onchain is just as important as designing the legal structure in the real world. Since tokenized securities are still securities, they must trade onchain in compliance with rules set by the issuer and the regulations of the relevant country.
Securitize, through its subsidiaries, is a SEC-registered broker dealer and digital transfer agent on the blockchain, fund administrator, and operator of a SEC-regulated Alternative Trading System (ATS). This provides Securitize the foundation to issue, manage, and support the trading and distribution of tokenized securities. Securitize also holds similar licenses in the EU, making it the only platform capable of issuing and distributing tokens in a fully regulated manner in both the U.S. and the EU.
The technical backbone of Securitize is the DS Protocol. The DS Protocol enables regulated issuance and trading of tokenized securities in an open ecosystem through DS Tokens, DS Services (Trust Service, Registry Service, Compliance Service), and DS Apps.
This article examines how the DS Protocol is implemented in practice through the BUIDL use case and offers a complete analysis of how Securitize works at a technical level. The goal is to help even readers who are not familiar with code understand Securitize’s technical architecture.
Since the Trump administration, regulations around the blockchain industry have been rapidly clarified, leading many companies and financial institutions to take an interest in blockchain. Among them, RWAs including stablecoins have drawn the most attention as they combine real world assets with the advantages of being onchain, offering higher efficiency and accessibility compared to traditional financial systems. It is now one of the fastest growing sectors.
Even excluding stablecoins, the RWA market has been accelerating in growth. The largest share of assets comes from private credit, followed by US Treasuries. In fact, RWAs cover a wide range of assets beyond private credit and Treasuries such as institutional alternative funds, equities, commodities, and corporate bonds.
Just as the types of assets that can be tokenized are diverse, so too are the protocols used to tokenize them. However, there is one platform that dominates the RWA market. That is Securitize.
Source: Securitize
For general investors, Securitize is best known as the platform that tokenized BlackRock’s BUIDL fund. It is a representative tokenization platform in the RWA market, providing services that bring a wide range of assets such as stocks, private credit, reinsurance, and VC funds onchain. Securitize is a formally registered Transfer Agent with the SEC, a Broker Dealer registered with both the SEC and FINRA, and also holds an ATS license, which enables it to issue and trade security tokens.
This establishes the legal foundation for Securitize to carry out the full lifecycle of tokenized securities in the United States in a regulated manner. Securitize is the only tokenization platform in the U.S. capable of handling the complete lifecycle of a wide range of RWAs, from issuance to distribution.
Because Securitize is the only tokenization platform in the U.S. that combines both technological and regulatory strengths, it has been chosen by numerous institutions, with its collaboration with BlackRock being the most notable example. The partnership is highly symbolic, as BlackRock selected Securitize to issue, manage, and facilitate the trading of its first tokenized fund, BUIDL. Furthermore, BlackRock not only issued tokenized securities through Securitize but also reinforced this partnership by making a significant investment of $47M in Securitize in May 2024.
Source: rwa.xyz
Securitize is without question the world’s leader in RWAs, having tokenized $3.1B worth of assets and holding nearly 20 percent market share. Its flagship RWA products include the BlackRock USD Institutional Digital Liquidity Fund (BUIDL), add Apollo Diversified Credit Securitize Fund (ACRED), Blockchain Capital III Digital Liquid Venture Fund (BCAP), and Mantle Index Four Fund (MI4).
What is interesting is that all of these different RWA tokens were tokenized through Securitize’s DS Protocol. To tokenize an asset, two things matter: 1) how to design the legal structure in the real world and 2) how to design the smart contract structure onchain. In this article, we will focus on the second aspect in detail.
Unlike regular tokens, tokenized securities require multiple mechanisms for regulatory compliance. For example, the issuance and transfer of BUIDL are only permitted for Qualified Purchasers who have completed KYC. Therefore, tokenized securities cannot be issued freely like ordinary tokens. It is crucial to ensure that issuers, investors, and exchanges can issue, invest, and facilitate trading in a fully regulated manner. This is the role of Securitize’s DS Protocol.
The DS Protocol provides issuers with tools to manage the entire lifecycle of tokenized securities and offers smart contract infrastructure for issuers, investors, and exchanges. This covers not only issuance but also dividends, voting rights, transfers, and trading.
The main components of the DS Protocol are as follows:
DS Token: An ERC-20 compatible token that includes not only the basic ERC-20 functionalities but also various extended features required for tokenized securities. Tokens such as BUIDL and VBILL are all DS Tokens.
DS App: Applications that handle different events in the lifecycle of tokenized securities such as issuance, trading support, voting, and dividend payments.
DS Services: The underlying infrastructure that enables DS Tokens and DS Apps to function, consisting of Trust Service, Registry Service, and Compliance Service.
The DS Protocol allows issuers, investors, and exchanges to handle tokenized securities in a fully regulated manner through DS Tokens and DS Services. To understand this, it helps to first see the overall picture and then examine the details.
A DS Token can be understood as an extended version of a regular ERC-20 token. Unlike ordinary tokens, DS Tokens cannot be transferred freely without conditions. Depending on the issuer, the Compliance Service, one of the DS Services, intervenes in transfer functions. When a DS Token is transferred, the Compliance Service checks:
Is the transaction compliant with regulations?
Is the recipient an authorized investor?
Does the transfer exceed any imposed limits?
When issuers allocate tokens to a wallet, the Compliance Service verifies eligibility. Beyond simple issuance, advanced features include imposing vesting conditions, burning an investor’s tokens, or forcibly recalling them.
Then how is a wallet distinguished as an issuer, an investor, or an exchange? This is handled by the Trust Service of DS Services. The Trust Service manages the role associated with each wallet address, functioning as the authority for role assignments.
How is the list of investors eligible to hold DS Tokens managed? This is the responsibility of the Registry Service. The Registry Service stores investor attribute data linked to wallet addresses, including nationality, accreditation status, and investor ID.
Let’s now take a closer look at these elements one by one and examine how tokens like BUIDL actually function onchain. Some code examples will appear, but if you follow along carefully, you should have no difficulty understanding the technical structure.
How are the core functions of the DS Token implemented?
2.4.1 Transferability
The first feature is transfer between eligible wallets. Before transfer() or transferFrom() is executed, the Compliance Service checks whether the transfer of tokens meets regulatory requirements.
The DS Token includes a modifier called canTransfer. For every token transfer, it executes the Compliance Service’s validateTransfer() to check whether the transfer is allowed.
If the transfer is not eligible, the transaction fails. Since this can waste gas, the DS Token and Compliance Service also provide a preTransferCheck() function that allows checking eligibility in advance. We will look at this in more detail in the Compliance Service section.
2.4.2 Issuance
There are three main functions for issuing DS Tokens. Through these, issuers can automate issuance to eligible wallets with features such as vesting.
issueTokens(address _to, uint256 _value): Issues new tokens to a specific wallet.
issueTokenWithLocking(address _to, uint256 _value, uint256 _valueLocked, string _reason, uint64 _releaseTime): Issues new tokens to a specific wallet while also setting the locked amount and unlock time, thus implementing vesting.
totalIssued(): Checks the total number of tokens issued so far.
2.4.3 Retrieving Wallet Addresses
In general, ERC-20 tokens do not have a built-in function to extract the complete list of wallets and their holdings. While balances of specific wallets can be checked, retrieving all wallet addresses at once is not possible. The DS Token adds functions to make this possible:
getWalletAt(uint256 _index): Returns the wallet address at a specific index in the holders list.
walletCount(): Returns the total number of wallets holding DS Tokens.
This ability to easily retrieve wallet addresses makes dividend distribution, audits, and regulatory reporting much easier.
2.4.4 Investor-Centric Management Functions
Because of legal requirements, tokenized securities often need to manage holders based on the number of investors. For example, certain regulations may restrict an issuer to a maximum of 200 investors. However, on the blockchain, one investor may hold multiple wallets. If each wallet were counted separately, it could appear to violate the regulation. Therefore, the Registry Service within DS Services manages which wallets belong to which investor. The DS Token contract provides a function to check the total DS Token balance held by an investor:
balanceOfInvestor(string _id): Queries the total number of tokens held by an investor ID, aggregating the balances across all wallets owned by that investor.
2.4.5 Issuer Control Functions
Wallet addresses assigned the issuer role by the Trust Service gain access to additional functions:
burn(address _who, uint256 _value, string _reason): Burns tokens held by a specific wallet. This can be used in scenarios similar to share buybacks.
seize(address _from, address _to, uint256 _value, string _reason): Forcefully transfers tokens from one wallet to another. This allows recovery and reissuance in case an investor loses access to their wallet.
isPaused(): Checks whether token transfers are currently paused. Issuers may suspend transfers entirely in cases of suspected regulatory violations, security incidents, or legal orders.
The Trust Service is a smart contract within the DS Protocol that manages the roles assigned to wallets. The four roles are None, Master, Issuer, and Exchange, represented on chain as the integers 0, 1, 2, and 4, respectively.
The function for assigning roles to wallet addresses is setRole(). This takes the wallet address and an integer corresponding to the role type, then defines that wallet’s role. For example, if the issuer wants to assign the exchange role to the address 0x123..., the issuer calls setRole(0x123..., 4) in the Trust Service.
The Registry Service records the list of investors eligible to hold DS Tokens on chain. It does not store direct personal identifiers such as names, social security numbers, or passport numbers but instead records attribute information such as nationality and accredited investor status.
As mentioned earlier, a single investor may own multiple wallet addresses. Each investor is therefore assigned a unique ID, and the wallet addresses owned by that investor are also stored in the Registry Service. The attribute information recorded in the registry helps the Compliance Service perform regulatory checks.
Investor registration and attribute assignment are managed through the following functions in the Registry Service:
registerInvestor(string _id, string _collision_hash): Registers an investor in the system using a unique identifier (_id). The _collision_hash is a hash value used to prevent duplicates.
setCountry(string _id, string _country): Assigns the investor’s nationality using a country code.
setAttribute(string _id, uint8 _attributeId, uint256 _value, uint256 _expiry, string _proofHash): Assigns attributes to an investor. Attribute IDs can be 0, 1, 2, 4, or 8, corresponding to none, kyc-approved, accredited, qualified, and professional. The _value parameter can be 0, 1, or 2 to indicate the status of the attribute (pending, approved, rejected). The expiration date of the attribute is specified with _expiry. Finally, _proofHash stores the hash of an off chain document (such as a passport photo or KYC report), which can be used by regulators to verify the original document if requested.
addWallet(address _address, string _id): Links a wallet address to an investor ID, since an investor may own multiple wallets.
The Compliance Service supervises all token transactions across the lifecycle of tokenized securities—including issuance, burning, and transfers—to ensure they comply with the issuer’s rules and applicable regulations.
2.7.1 Core Validation Methods
validateIssuance(_to, _value): Checks if issuance is allowed
validateBurn(_who, _value): Checks if burning is allowed
validateSeize(_from, _to, _value): Checks if forced seizure is allowed
validate(_from, _to, _value): Checks if a general transfer is allowed
These functions are automatically invoked whenever a transaction occurs with DS Tokens. In other words, when issuance, burning, seizure, or transfer takes place, the corresponding validation function of the Compliance Service is called. If the transaction violates any rules or regulations, it automatically fails (reverts).
For example, the code above shows the validateTransfer() function, which determines whether a transfer can occur (validate is implemented under the name validateTransfer). Inside the function, it calls preTransferCheck() to confirm whether the transfer is permitted.
The preTransferCheck() function verifies conditions such as whether the token is paused, whether the sender’s balance is sufficient, and whether the tokens are subject to vesting locks. It also calls checkTransfer() for additional regulatory logic. There are two approaches here:
In the whitelist approach, checkTransfer() simply verifies whether the wallet is registered as an investor in the Registry Service.
In the regulatory approach, instead of using checkTransfer(), it calls more complex regulatory logic from the ComplianceServiceLibrary to determine transfer eligibility.
2.7.2 Pre Check Methods
Since failed transactions waste gas fees, the Compliance Service provides pre check functions that allow issuers and investors to confirm eligibility before submitting a transaction.
preIssuanceCheck(_to, _value): Checks issuance eligibility before sending the issuance transaction
preTransferCheck(_from, _to, _value): Checks transfer eligibility before sending the transfer transaction
As described earlier, these functions reference the Registry Service to determine eligibility.
2.7.3 Country-Specific Regulation Management
The Compliance Service can also enforce restrictions based on country.
setCountryCompliance(_country, _value): Assigns a country to a specific jurisdiction. Based on how jurisdictions are configured in the ComplianceConfigurationService, this assignment determines whether transfers are permitted or if additional conditions apply.
getCountryCompliance(_country): Returns the compliance status for a specific country
Using this functionality, issuers can enforce rules onchain, such as restricting non US investors from participating in issuance or limiting secondary trading to investors from certain countries.
All the smart contract code and functions above may have felt overwhelming. Let’s analyze Securitize’s most representative DS Token, BUIDL, to see how the DS Protocol is actually implemented in practice.
First, the smart contract address of BUIDL is 0x77...2aec. How can we find BUIDL’s Trust Service, Registry Service, and Compliance Service? This can be done using the DS Protocol’s getDSService() function.
getDSService(uint _serviceId) returns the smart contract address of the service that corresponds to the input integer _serviceId. The service IDs for the Trust Service, Registry Service, and Compliance Service are 1, 4, and 8, respectively. Entering these directly in Etherscan reveals the following addresses for BUIDL’s DS Services:
Trust Service: 0x3a...6c60
Registry Service: 0x0D...1a5B
Compliance Service: 0x07...E3a9
By checking BUIDL’s Trust Service on Etherscan, you can see transactions where roles are assigned to specific wallet addresses.
For example, in transaction 0xa4...1680, the Trust Service’s Set Role function was called, assigning role 2 to the address 0xFC...5644. In the Trust Service, role 2 corresponds to the issuer.
Indeed, if you input 0xFC...5644 into the Trust Service’s getRole() function, it returns role 2.
Checking BUIDL’s Registry Service on Etherscan shows transactions that register wallets in the registry through event logs.
For example, in transaction 0x35...ef29, the Register Wallet function was called from 0x00...6cab. But wait—the Registry Service’s address is 0x0D...1a5B. What is 0x00...6cab? Looking at the internal transaction details clarifies this.
This shows the internal process of registering a wallet in the Registry Service. It includes checking the wallet’s role in the Trust Service (0x3a...6c60) and ultimately contains an internal transaction where 0x00...6cab calls the addWallet() function on the Registry Service (0x0D...1a5B).
If you query the wallet 0x8e...Ef45, which was registered in this transaction, using the Registry Service’s getInvestorDetails() function, you will see it is associated with investor ID 1b09...2251 and nationality United States.
The main role of the Compliance Service is to determine the eligibility of DS Token transactions. In fact, by checking the internal transaction list of a BUIDL token transfer transaction, you can see the following internal calls:
Validate Transfer: BUIDL Token → Compliance Service: The validateTransfer() function of the Compliance Service is automatically called to check whether the token transfer is allowed.
Get Investor, Get Country: Compliance Service → Registry Service: The Compliance Service queries the Registry Service with getInvestor() and getCountry() to retrieve the attributes of the wallet involved.
As the clear leader of the RWA market in terms of TVL, Securitize has built a wide range of mechanisms through smart contracts to ensure that tokenized securities can be traded onchain in a fully regulated manner. To achieve this, DS Services such as 1) the Trust Service for assigning roles, 2) the Registry Service for recording investor information, and 3) the Compliance Service for verifying eligibility, interact seamlessly. Based on these, the issuance and trading of DS Tokens can be carried out safely.
In addition, Securitize introduces DS Apps so that DS Tokens can be integrated into various smart contracts. DS Apps for dividend distribution and voting rights are provided by default if needed. Beyond that, DS Apps can also support more complex use cases such as managing token reserves and enabling automatic redemption in stablecoins when requests are made. For example, in the case of IHF, reserves in BUIDL were redeemed in USDC. More generally, these capabilities are designed to be flexible and support different stablecoins, allowing a wide variety of functions to be built around DS Tokens.
In summary, the DS Protocol of Securitize is designed with the entire lifecycle of tokenized securities in mind. Unlike other platforms that operate as closed systems, it pursues an open ecosystem where issuers, investors, app developers, and exchanges can all participate. This technical backbone has provided the foundation for Securitize to become the RWA market leader today.
While this article focused on how Securitize technically implements tokenized securities onchain, in the future we may look at what services Securitize actually provides and how the legal structures of tokenization are designed.
Dive into 'Narratives' that will be important in the next year
Securitize
Bitcoin
Arch
OVERTAKE
