sRFC 00020: RWA/Security Token Standard


This sRFC proposes the development of an open-source Real World Asset (RWA) Security Token standard, specifically focused on real estate, but applicable to many other applications, to foster wider adoption of these assets on Solana. The establishment of a standardized framework for tokenizing real-world assets (“RWA”) holds the potential to significantly enhance transparency, accessibility, and efficiency in real estate transactions. This development would bring about substantial benefits for consumers and institutions involved in building and utilizing products within the DeFi space, ultimately contributing to the onboarding of the next 100 million users to the Solana ecosystem.


Real-world assets (RWAs) are physical or tangible assets that have value and exist in the real world. Examples of RWAs include real estate, artwork, commodities, vehicles, etc. These assets are typically illiquid due to their physical nature, and their ownership is governed by legal documents. However, blockchain technology presents a unique opportunity to digitize or “tokenize” these assets, making them easily tradable and accessible to a global audience.

Tokenization of RWAs, in the context of real estate, involves converting the rights to an asset into a digital token on a blockchain. Real estate tokenization could bring about a fundamental transformation in the way real estate is owned, traded, and financed. However, the lack of a unified and widely accepted standard for real estate tokenization in the Solana ecosystem is a major impediment to this transformation. This proposal seeks to address this issue by establishing an open-source, ecosystem-endorsed standard for tokenizing real estate on Solana.

The Problem

As it stands today, the Solana ecosystem lacks a unified, widely-accepted standard for real estate tokenization. While Ethereum hosts numerous token standards that apply to real world assets, Solana predominantly relies on Metaplex’s Token Metadata Standard which was created for broad use NFTs. While Metaplex’s standard is great for general NFTs, it lacks crucial features required to allow for the mass adoption of real world assets like escrow facilities, token freeze/nullification, and a standard approach to property data input.

Proposed Solution

Create an open-source, ecosystem-endorsed standard for tokenizing real estate on Solana. This Real World Asset (RWA) standard aims to not only simplify the tokenization process for new entrants but also get broader adoption from existing real estate developers, brokerages, institutions. The development of this standard would thus serve as a public good, spurring growth in Solana’s RWA landscape.

Functional Requirements of the RWA Standard

Commoditized RWA Standard

  1. Title Ownership: Ability to verify the legal ownership of the property by providing verified documentation or parsing via a third party data oracle.
  2. Title Status: Ability to confirm whether the title is clean or dirty depending on liens (legal claims or holds on a property, either by financial institutions or other parties, to secure the repayment of a debt).
  3. General Property Info Update (Updated via trusted RE Data Oracles)
    1. Address Update: Ability to update the property’s address.
    2. Square Footage Update: Ability to update the property’s square footage.
    3. House alteration / major renovations

Securitized RWA Standard

  1. Issuer Transaction Clawback: Ability for the issuer to clawback or reverse transactions if necessary.
  2. Trading Halt Functionality: Ability for the issuer to halt trading in certain circumstances.
  3. Issuance Whitelist: Ability to maintain and update a whitelist for issuance, controlling who can issue the tokens.
  4. Secondary Trading Whitelist: Ability to maintain and update a whitelist for secondary trading, controlling who can trade the tokens after issuance.
  5. Escrow Mechanism: Ability to implement an escrow mechanism, providing a secure way to hold funds or assets until specified conditions are met.
  6. Regulatory Filings Verification: Ability for the public to verify that regulatory filings have been completed, ensuring regulatory compliance.
  7. Dividend Distribution: Ability for the issuer to distribute dividends (such as rental income) to token holders.
  8. Dividend Distribution Schedule Updates: Ability for the issuer to specify and update the schedule for dividend distribution.

Potential Drawbacks

Despite the potential advantages, a few potential drawbacks could arise from this proposal.

  1. Regulatory Complexity: Due to the legal and financial nature of RWAs, particularly real estate, different jurisdictions may necessitate varying levels of regulatory compliance, potentially complicating the adoption process.
  2. Oracle Dependency: The proposed standard would rely on trusted data oracles for real-time information updates, any disruption to these services could potentially impact the overall system’s operation.
  3. Adoption Challenges: Though the standard would simplify the process of tokenization, achieving wide-scale adoption might be challenging, particularly from traditional real estate players unfamiliar with blockchain technology.
  4. Privacy Concerns: Handling sensitive property information on-chain could raise privacy concerns. We need to ensure the appropriate safeguards to prevent unauthorized access and maintain privacy.


The tokenization of real-world assets such as real estate holds the key to unlocking untapped value by democratizing access, enhancing liquidity, and improving efficiency. This proposal aims to provide a robust framework that will help fuel the growth of the RWA landscape within Solana, bringing us a step closer to realizing the vision of truly decentralized finance. The open questions mentioned are essential for the community to resolve together to ensure that the proposed standard is both practical and compliant with regulatory standards.

Open Questions

All of the above is open to comments. Some specific questions to Resolve with 3rd Party Partners are listed below:

  1. Should the standard support multiple US Security Regulations from the get go?
  2. How should title claims be handled?
    1. How are claims tracked?
    2. How are claims proven?
    3. What data should be uploaded for title claims? (title reports)

Very cool. No strong takes overall, but having worked at a real estate data startup, you will quickly find that the fields in the ‘Commoditized RWA Standard’ as you have them are insufficient (there will be hundreds of fields worth tracking). Would recommend a flexible approach to fields there.


This is a great idea and a FANTASTIC start to solidify Solana as the ideal chain for RWA solutions. I agree the Metaplex standard does not sufficiently account for the unique nature of RWA’s and their specific requirements in a token.

The reliance on oracles is always a concern, particularly if they rely on government recognition of any of the documents. Do you propose that documents be uploaded to arweave and stored on-chain with a link in the metadata to the title? Would the plan be to eventually incorporate governmental oversight into the transactions, and allow for government offices to sign on-chain transactions and transfers?

Wallet security. The revocable nature of the token is beneficial in that if someone is hacked the original token can be voided and re-issued, however, this also gives power to individual bad actors to make changes to the title that would normally require governmental recognition. How would one determine whether someone was hacked and lost their tokens or if they actually completed an off-chain transaction and transferred the token to the new owner, and attempted to claim it back? If the solution is a multi-sig, who are the signers?

KYC: If allowing for certain forms of financial actions or distributions would the token issuer be responsible for completing KYC? Would the tokens require permissioned transfers? How does one prevent potential violations of US Treasury sanctions or laws without a permissioned system?

The UCC also becomes particularly relevant here with regard to understanding one’s rights in the event of a default of an RWA in which the token represents the legal title. Can defaults trigger instant title transfers on chain in the event of a default? What would be physically necessary for the government to recognize those claims?

These are some of my initial thoughts off the cuff but I have been working on thinking through this issue for some time and would love to keep the conversation going here.


Thanks for initiating this discussion - much needed. Great points, but I would argue that a generic RWA standard like Token 2022 would make more sense, as it would allow for greater configuration flexibility. For a specific use-case like Real Estate, projects can build low/no-code solutions on top of these standards to enable even traditional firms to tokenize their assets.

P.S. I was also working on designing an RWA token standard - essentially Permissioned Tokens (including the flowchart) - and would love to hear community comments.


I do believe that at the core of this standard permissioned tokens are a requirement, but I slightly disagree that an RWA Token Standard is essentially Permissioned Tokens. My thoughts are more along the lines of a “configurable” permissioned token that would allow the issuer to specify whether or not this token will be treated as a commodity or security and implement their own respective logic. The distinction between the two is important especially in the case of institutional adoption (funds would trade as securities). Depending on the “RWA Type” the issuer would be responsible for implementing certain functions such as a “Title Verifier”/“Legal Verifier” required by the Standard.

Ex. You want to tokenize your car: Create an RWA token of type Commodity. Implement the “Title Verifier” function (and whatever else might be required by the Standard) and you’re good to go.

Would love to hear your thoughts on this!


Great input and deep need for this in the ecosystem.

Some thoughts:

  • Claims should be tracked & proven by providing PDF or link to county’s recorder office. A PDF should suffice of the title report and/or deed.

  • Regarding clawbacks, I think adding a freeze element would also be beneficial in the case where manual verification is needed.

  • How would you handle different regulatory requirements for a single offering? (Accredited Investor, Non-acccredited, Non-US) Specifically for different transfer restrictions for each? How are you verifying the end-buyer is confirming / acknowledging their acceptance of a restricted security token?

Appreciate the pioneering efforts to bring RWA’s to Solana!

Props & Love to the Homebase Team

Odai - LiquidProp


Hey Dom, thanks for the well thought-out post. This is a great opener for what I think will be the killer app of Solana DeFi. RWA’s need fast chains. They are currently severly hampered by slog that is the EVM.

That being said, there are a few areas in your proposal that I’d like to comment on, most of which have also been pointed out by other members of this forum:

Real-Estate Focus - The language in the post appears to be largely tailored to Real Estate and might not fully encapsulate the wide range of possibilities that RWAs present. As we’ve observed, tokenized funds have gained considerable traction and could be the current primary market fit for RWAs on the blockchain.

USA Focus - The proposal seems to focus heavily on the US jurisdiction, an environment we know is susceptible to frequent and substantial regulatory changes. Rather, I suggest we consider areas where blockchain standards already have governmental support, like the EU.

Usage of Oracles - I recognize the need for updatable tokens/NFTs, but this brings up important security considerations that might pose obstacles to the broader adoption of the standard.

Regarding your closing queries:

  • I agree that we should take into account various regulations and perhaps work towards a flexible, jurisdiction-agnostic “category-based” model.
  • Title claims seem simple to track, at least based on my tech knowledge and talking with the people behind ERC-6065 (the EVM RWA standard). As each property would be a unique token, the tracking is inherent to the chain.
  • Ownership of a unique token could indeed be used as proof of ownership for the underlying asset.
  • While uploading data for title claims poses challenges, I believe that current developments in decentralized storage solutions, such as Filecoin and Arweave, show promise in addressing this issue.

I would be thrilled to contribute further to these discussions. We have extensive experience in developing a MiCA-compliant stablecoin, a general EU-based tokenization framework, and have contributed to some Solana-based projects in the past. Additionally, I am also deep in the RWA scene on Ethereum, and have been following and discussing the ERC-6065 spec for some while now.

Please feel free to reach out to me at joakim(at) or via Telegram at @jommi to continue this conversation. Would love to collaborate!


Thanks for the feedback Joebuild!

I started this post with a focus on real estate, but after multiple discussions with other teams, it’s clear we need a more general RWA standard that can then be customized for different verticals (trading cards, real estate, commodities, etc)

Completely aligned that for the specific real estate vertical, there needs to be flexible approach to field input


Thanks for the feedback Odai!

  • Agreed that claims should be tracked and proven either via PDF (ideally a document with some level of “official” stamp) or link to county recorder’s office

  • Freeze element would be crucial, especially to comply with US securities regulation

  • With the assumption that the RWA standard would just be the framework for how to tokenize physical assets, depending on the jurisdiction, a regulatory wrapper would be needed specific to the country that you’re issuing the token in. In the case of the US wrapper, the issuer would still need to make sure they’re complying with US securities regulation when issuing the token (whether you sell to accredited investors only, non-accredited, etc). The RWA Standard would then ensure that you to have the right tools at your disposal to comply with different US securities regulation (For example: In the case of a Reg D filing, the tokens would automatically be frozen for 1 year after initial sale, etc). In addition, after the sale, the RWA Standard should ensure that the security tokens comply with Rule 144 (US specific).

  • In terms of verifying that the end-buyer is confirming / acknowledging their acceptance of a restricted security token, it’s likely that trading of security tokens (at least in the US) is primarily done on a permissioned DEX or CEX. The reason is that some entity needs to perform KYC on each user to comply with US regulation, and likely needs an alternative trading system license (ATS) to allow for P2P trading.

If you have any other thoughts on this, or disagree with any of my statements, would love the feedback! Very much thinking out loud here based on how I believe it’d work based on multiple discussions with lawyers, other teams, etc.


Hey Whisky, thanks for being a part of the discussion!

I agree that reliance on oracles would be a problem. In the initial state of the standard I envision document upload (title/deed + SEC docs if securities) to be done in a similar manner to NFT data. This would mean that issuers are responsible for uploading the correct documentation. In an ideal world we have some sort of Oracle provided by government or with government oversight that allows us to undeniably verify the validity of the uploaded documents. I would love more discussion around this piece!

Wallet security – this is an interesting one. It’s important to note that ideally the token truly represents legal title/ownership. Unfortunately there may be no way to universally guarantee that every token issuer has done the proper legal filing to support that without the involvement of governments/other third parties. To me, this means that it is very likely a decision that the issuer of the token will make as opposed to the standard per say. Security tokens require, legally, the capabilities for tokens to be voided and re-issued. How and when you do that is completely up to the issuer (ideally the issuer has a process in place for how they identify the legitimacy of a hack).

KYC: At it’s core the standard would be a Permission Token. If issuing the token as a security, issuers would have the ability to whitelist holders upon completion of KYC through their own third-parties. @yashhsm shared a flowchart below that showcases this! This would dictate who can perform what financial actions such as transfers, receipt of dividends, etc…

With regards to UCC, in an ideal state, yes defaults should trigger instant title transfers. Especially if loans are made on-chain. However, absent government adoption, this is likely not possible in countries that wouldn’t enforce this title transfer legally.

My takeaway from several discussions is that the standard itself likely cannot make guarantees on the validity of the documents uploaded without the involvement of government bodies (ex. SEC allowing us to verify the validity of security filings on-chain for a certain RWA token). These processes also vary from locale to locale, therefore making it difficult to build a standard that satisfies everyone, everywhere. What we can do is create a standard that defines a structured set of data requirements (documents to upload, parameters to set, etc…) and functional requirements that are required amongst most/all locales and leave it to issuers to build systems on top of that. Hopefully as time goes on that standard evolves and gets support from government bodies to achieve that aforementioned ideal world scenario. In short, I think it’s important that the standard remains robust and quite open to implementation by the issuer, so that it can be used in various locales/jurisdictions.


Thanks, Dom!

Agree with @yashhsm above - we should also be looking to create a more universally programmable security token asset/standard that many different types of ST/RWAs can be tokenized with (equity, debt, rev shares, etc.). The tracking of deed ownerships and even geodata associated with a property is interesting AND I don’t know that there is a market asking for this…

Token 22 was a good start and an even more adept ‘transfer restricted token standard’ or ‘security token’ standard can address RE RWAs and a broader spectrum of assets.

On NFTs, I have experience in security non-fungible token (sNFT) and while they’re novel for delivering financial upside to investors based on more origination (the creator) and copy/IP rights, they are far less adept than fungible assets when wanting to build (1) deep and high volume secondary markets and (2) composable finance. You can still have things like dividends, royalties and profit-taking distributions track against fungible token supplies all the same.

So, if we’re wanting a non-fungible RE specifically, this can be fine. I am unsure of the market size or problem being solved with such an asset standard. If we’re wanting to deliver a security token standard that is broadly configurable can create composable financial markets a la ERC-1404, I recommend going towards… that. This would open up far more developer contribution and value generation on Solana.


Hello Dom,

Thank you for initiating the discussion. I strongly echo @JoakimEQ’s sentiment; a flexible, high-level data model with optional fields would likely serve issuers & other counterparties better globally.

Membrane Finance builds technologies to facilitate hybrid financial markets. We are currently bringing a MiCA-compliant stablecoin to Solana and we would be happy to contribute to the development of the new standard through our learnings and experience.

Please feel free to reach out to me at juuso.roinevirta(at)membrane(dot)fi or via Telegram at @roinevirta – we would be happy to collaborate and ensure global compatibility.


@Sherwood great commentary!

Genuine question, what makes you say this?

IMHO this is not necessarily true, but more a function of how the DeFi markets have developed thus far. Specifically, that all systems have historically been built to simply pool assets because it’s “how things are done”. I’ll admit it is certainly easier and often also cheaper for compute, but I think primarily this is a result of historical implementation baggage that originated with Ethereum and have been perpetuated over time.

Somewhat recently, from many of the more established players on Ethereum we’re seeing an evolution where platforms are creating more finely grained “pools” or other work arounds to solve for compliance and risk mitigation needs. Curve, Uniswap, Aave (and more) have all been taking these approaches which imho could be better solved by either ERC-1155 or ERC-1404 (or some improved smart contract designs around ERC-20 and ERC-721). I’ve long felt this way and did some early implementations 4-5 years ago but only recently started exploring this again more earnestly.

Curious if I’m missing something. Happy to take to DMs to prevent polluting here.


Love this thinking and feedback. When we think about 1155, that can be a great way to conceptualize indexed fungible assets associated with one originated (using securities language) asset.

I think that you can absolutely go down these routes and, bc you want to develop markets* MORE than wanting to create just more assets* and fungibility is key to this. Making the standard more fungible-capable open at first would just be a simpler place to start and would accomplish the markets creation.