# 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:

1. **What is the asset, legally and operationally?**
2. **Who is responsible for maintaining its real-world state?**
3. **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.

| Role                | Responsibility                             |
| ------------------- | ------------------------------------------ |
| 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:

```
Asset Definition
     │
     ▼
Legal & Role Mapping
     │
     ▼
On-Chain Token Design
     │
     ▼
Attestation Setup
     │
     ▼
Token Issuance Enabled
```

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.