
Author: JoĂŁo Lages
A security token is not a new asset class. It is a digital representation of a security or another regulated investment claim, operated through distributed-ledger infrastructure. The token may represent a share, bond, fund unit or asset-linked note, but the investor's rights still come from company law, the instrument terms and the issuer's obligations—not from the token's appearance in a wallet.
This distinction is the starting point for evaluating any security-token project. A technically sophisticated token can still represent a weak claim, sit outside the authoritative ownership register or depend on an issuer with poor controls. Conversely, a conventional-looking debt instrument can use token infrastructure effectively for issuance, eligibility checks, ownership records, voting and distributions.
For issuers and professional investors, the useful question is therefore not “Is this on-chain?” It is “What legal right exists, who owes it, which record controls ownership, and how does the system behave throughout the investment's life?”
A security token should be analysed in two connected layers. The legal layer defines the instrument: issuer, principal or equity interest, ranking, voting, distributions, maturity or exit mechanics, transferability and enforcement. The technical layer represents that instrument on a ledger and implements approved operational rules.
The two layers must agree, but they are not interchangeable. Smart-contract code cannot give an investor rights that the issuer never validly created. It cannot perfect security over an asset without the steps required by the relevant property and insolvency law. It cannot convert an unsecured note into direct ownership of the property financed by the note.
A credible structure answers four questions before token development begins:
The label describes the digital form, not a uniform risk profile. The underlying instrument determines what investors can claim and how the product should be valued.
An equity token may represent an ordinary or preferred share. Investors may receive voting, dividend, information and liquidation rights, subject to the company's constitutional documents and applicable company law. The decisive issue is whether the token holder is recognised on the legally effective shareholder register or has only a contractual claim against an intermediary that holds the shares.
That difference changes insolvency exposure and governance. A direct registered shareholder can exercise company-law rights. A token referencing shares held by a nominee may give the investor a beneficial or contractual interest whose voting and distribution mechanics depend on the nominee arrangement.
A debt token can represent a bond, note or other repayment obligation. Its value depends on the issuer's credit, ranking, collateral, covenants, cash-flow source and maturity—not simply on the existence of an underlying asset. A note “backed by real estate” may be secured over property, secured over shares in a property company, structurally subordinated behind senior lenders or entirely unsecured. Those are materially different exposures.
A token can also represent a unit or share in a collective investment vehicle. In that case, fund classification, management, depositary, valuation, subscription and redemption rules matter. Tokenization does not remove the need to determine whether the arrangement is an alternative investment fund or another regulated collective structure.
An issuer may create a note whose return is linked to the income or sale proceeds of an identified asset. The investor generally owns the note, not the asset itself. The documentation must explain the reference formula, expenses, valuation process, conflicts, waterfall and what happens if the asset is never sold. This structure is often more workable than pretending that each token is a direct fragment of title to a physical asset.
Security-token design is best understood as a sequence of controlled events rather than a one-off mint.
Automation is valuable where the underlying rule is objective. It can calculate a coupon from verified inputs, establish a voting snapshot or reject a transfer to an ineligible address. It is less suitable for decisions involving discretion, disputed facts or fiduciary judgment. Those decisions need an authorised human process and an auditable override path.
Consider an SPV that issues notes to finance a portfolio of business loans. Each token represents a defined nominal amount of the note. The note terms establish interest, maturity, ranking, covenants and events of default. The SPV owns the receivables or holds a properly documented participation in them; the token itself does not create that ownership.
Investor money should move through identified accounts and be deployed according to asset-eligibility rules. Borrower payments enter a collection account and are applied through a waterfall: taxes and senior expenses, servicing costs, reserves, interest, principal and residual amounts. If the servicer fails, the structure needs data access and replacement rights. If loans default, investors need clear workout and voting procedures.
The token layer can maintain the holder record, enforce transfer eligibility and allocate distributions. It cannot replace credit underwriting, borrower documentation or control of collections. Two projects with identical token code can have radically different risk because the loan pool, security package and servicing arrangements differ.
This is a practical decision point for an issuer: tokenization is useful when there are enough investors, transfers, distributions or reporting events to justify the infrastructure. For a single lender holding one bilateral loan to maturity, a conventional register may remain simpler.
A company can issue shares represented digitally, or an SPV can hold company shares and issue investors a separate security. The first model can provide direct shareholder status if local law and the corporate register support it. The second model gives investors exposure through the SPV and centralises the startup's cap table.
The SPV route can simplify the underlying company's governance, but it adds another legal layer. Investors need to understand fees, voting arrangements, follow-on rights, dilution, information flow, transfer restrictions and the SPV's treatment if the startup is sold. If the SPV's token holders vote on major decisions, the timing must allow the SPV itself to exercise the underlying shareholder vote.
A direct equity token creates a different operational burden. Share transfers, pre-emption rights, drag-and-tag provisions and corporate actions must stay synchronised with the token register. If a token moves but the legally recognised shareholder register does not, the structure can produce competing ownership records rather than efficiency.
A security token cannot normally circulate like an unrestricted payment token. The issuer may need to limit holders by jurisdiction, investor category, sanctions status, concentration, holding period or other conditions. Some restrictions are static; others change when an investor's status or the applicable law changes.
Permissioned-token standards can support this architecture. For example, ERC-3643 separates token functionality from identity and compliance registries so that eligibility rules can be checked before a transfer. That is an implementation standard, not a legal approval. The issuer still needs to define the applicable rule, keep investor data accurate and assign responsibility for exceptions and updates.
Recovery design is equally important. Institutional and retail products cannot assume that loss of a private key permanently destroys a legal security. A controlled recovery process may freeze the old address and reissue the position after identity and evidence checks. The legal terms should authorise that process and protect against duplicate claims.
Wallet control does not always equal legal ownership. An investor may control a self-hosted wallet, use a custodian, or hold through an omnibus arrangement. Each model changes key management, asset segregation, recovery, transaction approval and insolvency exposure.
The authoritative register must be explicit. If the on-chain ledger is merely operational, it should reconcile to the legally effective record. If national law recognises a DLT register as constitutive, the operator must still address corrections, court orders and continuity if the technology or service provider fails.
Settlement also requires a cash leg. Delivering a security token against a bank transfer can create timing and principal risk. A coordinated process, escrow or qualifying tokenized cash arrangement may reduce that risk, but the legal status of the payment asset and the responsibilities of each operator need separate analysis.
The classification starts with the instrument's characteristics. Under MiFID II, transferable securities, units in collective investment undertakings and other listed categories are financial instruments. ESMA's classification guidelines apply a substance-based analysis to crypto-assets. A token can qualify as a financial instrument even if it uses novel technology or terminology.
This boundary also determines whether MiCA applies. MiCA excludes crypto-assets that qualify as financial instruments. A security token does not become a MiCA instrument merely because it is issued on a blockchain; the relevant securities framework continues to apply.
For an offer of transferable securities, the Prospectus Regulation, consolidated on 5 June 2026, governs when a prospectus is required and which exemptions or national thresholds may be available. An exemption from publishing a prospectus does not remove issuer liability, fair-communication standards or the separate authorisation analysis for placement, advice, order reception or execution.
The EU DLT Pilot Regime, applicable since 23 March 2023, allows authorised DLT market infrastructures to request limited exemptions for trading and settlement of eligible DLT financial instruments. It is not a general authorisation for every token issuer or platform. In June 2025, ESMA recommended amendments to make the regime more usable and potentially permanent, but firms must still assess the law in force and the permissions of the specific infrastructure they intend to use.
Fractional denominations and technically transferable units can lower some access and administrative barriers. Liquidity requires more: willing eligible buyers, reliable information, price discovery, a permitted trading or bilateral-transfer process, custody and cash settlement. Private-company shares, project notes and asset-linked securities may remain difficult to value and infrequently traded.
An issuer should describe the actual exit route. A bulletin board that lets investors express interest is not an order book. An issuer-facilitated transfer is not guaranteed redemption. Admission to a venue does not guarantee volume. Liquidity claims should address expected holding period, transfer conditions, pricing method and the possibility that no buyer is available.
The strongest use cases have recurring operational complexity: multiple investors, eligibility-controlled transfers, frequent distributions, corporate actions, cross-party reconciliation or a need for durable audit trails. The weaker use cases add a token to a small, static transaction without changing how ownership, servicing or settlement works.
Issuers comparing solutions should examine the full operating model: which legal instruments are supported; who performs regulated distribution; how identity and transfer rules are maintained; whether custody is optional; how payments and corporate actions are processed; which record is legally authoritative; and what happens if the platform must be replaced.
Lympid's white-label investment-platform infrastructure is relevant when an issuer needs a coordinated investor journey, token administration and regulated-distribution arrangements. It does not replace the issuer, advisers, custodian or market infrastructure where those roles are required.
For deeper context, see the analysis of token claim architectures, the comparison of European tokenized-securities platforms and the guide to a European legal tokenization setup.
The final decision should be proportionate. Use a security token when it improves an identified ownership, compliance, servicing or settlement process. Do not treat the token as proof of title, asset quality, liquidity or regulatory approval. Those conclusions must be supported independently by the legal structure and the operating evidence.