Tokenization & RWA
Before choosing a tokenization platform, an asset owner can verify four things: title, constraints, approvals, and documentation. The article explains how, and why a defect weighs more when an asset has many token holders.
Imagine the owner of a commercial building who wants to find out whether it could be tokenized. They contact a technology provider, see a demonstration, and discuss which type of token to use. Then, rereading their own contracts, they find two things nobody had considered: the loan secured on the building requires the bank’s consent for operations that change rights over the property, and a long-term lease limits what can be offered to third parties. The technology would not have changed either fact. It simply brought them to light after time and budget had already been spent.
This is an illustrative example, but it points to a mistake in approach that tokenization readiness is meant to prevent: starting from the platform or the type of token and leaving for later the hardest part, the one that concerns the asset itself.
What Tokenizing Means
To tokenize an asset means to represent digitally, through a token recorded on DLT infrastructure, certain rights connected to that asset. Depending on the legal structure, the token may document an existing right or form part of the mechanism through which that right is issued, held, or transferred. In every case, the applicable legal framework depends on the rights involved and on the structure of the transaction, not simply on the technology chosen.
This is why the first question is not about technology. An asset is not ready for tokenization just because it exists: first, it must be possible to demonstrate who can dispose of it, under what conditions, and subject to which constraints. This preliminary check is what I call asset readiness: the first level of tokenization readiness, that is, the assessment that comes before the design of a tokenization transaction.
Four Checks Before Choosing the Technology
An owner can begin with the documents already at hand. Understanding the first issues to clarify does not require knowing DLT technology, although some answers will later need qualified professionals.
The first check concerns title. Does the name on the official documents match the person who intends to proceed? Are there other holders, even for small shares? If the asset belongs to a company, does the person representing it have the powers needed to start an operation of this kind? These are points to verify against the documents, not to take for granted.
The second concerns the constraints on the asset. Mortgages, pledges, leases, loan covenants, and third-party rights can limit what the owner is authorized to do. An encumbered asset is not necessarily unsuitable for tokenization, but its constraints must be known and their effects understood before deciding which rights could be represented or transferred.
The third concerns the approvals required. Shareholders, general meetings, lending banks, or competent authorities may need to be involved, depending on the asset and the planned operation. If a consent is required, it is best identified at the start. Discovering midway that someone must authorize the operation can change its timing, its terms and, in some cases, its very feasibility.
The fourth concerns the documentation available. Title deeds, registry extracts, contracts, certifications, and, where the asset generates income, financial statements must be verifiable, up to date, and easy to retrieve. Knowing that a document exists is not enough: it must be possible to examine it and to tell whether it correctly describes the current situation. Anyone evaluating a project needs to start from documented information, not only from a presentation.
These checks apply, with the necessary differences, to other types of assets as well. A building calls for documents on ownership, on the condition of the property, and on permitted uses; a machine or a collection calls for proof of title and documents of a different kind. The principle stays the same: before representing a right digitally, one must be able to show what that right includes and what limits it carries.
Why These Checks Matter in Tokenization
Many of these questions would also arise in a traditional sale. The difference is not that tokenization introduces entirely new problems, but that the structure of the transaction can magnify their consequences.
In a sale, owners, lenders, creditors, and other parties may be involved. In a tokenization project, depending on the rights represented and on how they are distributed, there may be numerous token holders, transfer restrictions, and disclosure obligations that last over time. A defect in the documentation or in the definition of the rights can therefore affect many positions at once. Correcting it after issuance, especially if the tokens have already been transferred, can become more complex and more expensive.
This is why I consider asset readiness a stage distinct from technology design. It does not settle every question tokenization raises, but it makes it possible to approach the next ones from a known starting point.
Once title, constraints, consents, and documentation are clear, fundamental decisions remain: which rights to represent, which entity will issue them, which legal structure to adopt, and which rules will apply to any offering. These assessments are developed with the relevant professionals and, for the infrastructure aspects, with the technology provider. The four initial checks do not replace that work: they are its foundation.
What Changes for the Owner
The goal is not to show that the asset is perfect. It is to tell apart what is already documented and usable, what needs clarification or intervention, and what could prevent the operation or change its structure.
This makes it possible to approach the next steps with greater awareness. With a legal advisor, you discuss facts and documents, not just intentions. With a technology provider, you reason about the rights that can actually be represented. With whoever will evaluate the operation, you present a more transparent picture, including the questions still open.
Of course, a preliminary check carried out by the owner does not replace professional due diligence or legal advice. Rules on title, constraints, and authorizations vary by jurisdiction, by the nature of the asset, and by the structure of the operation. Even complete documentation does not, by itself, show that a project is economically sustainable or legally feasible. It does, however, help identify which questions need deeper analysis before further resources are committed.
Where to Start
The first step can be very simple: prepare one page with the name of the asset, the party that holds title, the known constraints, the approvals that may be needed, and the documents available. The missing information shows where to concentrate the first checks.
Three situations can emerge from this review: an asset with a documentary basis clear enough to move on to further analysis, an asset that requires preliminary work, or an asset facing obstacles that call for reconsidering the operation.
Tokenization starts from the asset, not from the token. Whoever completes these checks before choosing a technology arrives at the first discussion with a clearer understanding of what they own, of the rights they could represent, and of the conditions still to be settled.
