Asset Onboarding Framework
Asset onboarding defines which real-world assets can be tokenised, under what conditions, and where responsibility lies when off-chain reality meets on-chain logic. This framework is intentionally conservative: onboarding is not about speed or volume, but about clarity, enforceability, and long-term integrity.
The protocol does not attempt to automate legal judgment. Instead, it provides a structured interface through which assets can be represented on-chain without collapsing legal, custodial, and technical roles into a single entity.
Purpose of Asset Onboarding
The onboarding process exists to answer three questions before any token is issued:
What is the asset, legally and operationally?
Who is responsible for maintaining its real-world state?
What guarantees can the blockchain reasonably enforce?
Only when these questions are explicitly addressed does tokenisation proceed.
Asset Eligibility Criteria
Not every asset is suitable for decentralised tokenisation.
An asset is considered eligible when:
ownership or entitlement can be clearly defined
supply and issuance can be bounded
state changes can be attested to
transferability rules can be expressed on-chain
Assets that rely on discretionary control, opaque valuation, or unverifiable state changes are explicitly discouraged.
Eligibility is assessed at the framework level, not by protocol fiat.
Roles in the Onboarding Process
Asset onboarding separates responsibilities across distinct roles.
Asset Originator
Brings the asset into the system
Issuer
Defines token structure and issuance rules
Custodian / Trustee
Maintains off-chain asset control
Attestor
Provides proofs or confirmations
Protocol
Enforces on-chain logic and constraints
No single role has unilateral authority over both the asset and the token.
Legal Structuring Assumptions
The protocol assumes that:
assets remain governed by real-world legal frameworks
token holders receive defined rights or claims
enforceability ultimately rests on external legal mechanisms
Tokenisation does not replace contracts, custodians, or courts. It replaces opaque coordination and manual reconciliation with deterministic, auditable logic.
Legal structure is treated as a precondition, not an afterthought.
On-Chain Representation Boundaries
A critical part of onboarding is defining what the blockchain represents — and what it does not.
On-chain state may represent:
ownership of tokenised claims
entitlement to cash flows
transfer restrictions
lifecycle events (issuance, redemption, freeze)
It does not represent:
physical possession
discretionary management
legal enforcement itself
This boundary prevents the protocol from asserting control it cannot enforce.
Asset Onboarding Flow
At a high level, onboarding follows a fixed sequence:
Skipping steps is not supported. Each stage exists to surface risk early rather than defer it.
Attestations and Proofs at Onboarding
Where direct verification is impossible, onboarding relies on structured attestations.
Examples include:
confirmation of asset existence
confirmation of custody arrangements
confirmation of issuance limits
Attestations are:
explicit
attributable to specific actors
updatable over time
They are not treated as immutable truth, but as auditable claims.
Issuance Constraints Defined at Onboarding
Supply control is defined during onboarding and enforced thereafter.
At a conceptual level:
Total Token Supply≤Legally Issued Asset Units\text{Total Token Supply} \leq \text{Legally Issued Asset Units}Total Token Supply≤Legally Issued Asset Units
Once issuance parameters are set:
minting follows protocol rules
burning and redemption are governed
arbitrary supply changes are disallowed
This prevents silent dilution or over-issuance.
Why Onboarding Is Intentionally Conservative
Most failures in RWA tokenisation occur before the first transfer, not after.
Common failure modes include:
unclear role separation
hidden custodial control
ambiguous legal claims
unverifiable asset state
By forcing these issues to be addressed during onboarding, the protocol reduces downstream risk for:
investors
secondary markets
integrators
Onboarding as a Trust-Minimization Layer
The onboarding framework does not eliminate trust — it contains it.
Trust becomes:
role-specific
inspectable
limited in scope
This allows participants to reason about risk explicitly rather than relying on marketing or reputation.
Last updated