# Introduction

<figure><img src="/files/B8aGAOX9rHxNJLQIDnLz" alt=""><figcaption></figcaption></figure>

#### *Stobox Tokenization Onboarding Framework v3.5. Security-Token-Only Digital Securities Workflow*

***

### **Purpose of the Framework**

The **Stobox Tokenization Onboarding Framework v3.5** is the official, standardized process for launching **Security Token Offerings (STOs)** on the **Stobox 4 enterprise tokenization platform**. It exists to ensure that every issuer follows a compliant, transparent, and technically sound methodology when creating digital securities that represent regulated financial instruments.

Security tokens differ significantly from other token types. They carry legal rights: ownership, claims, dividends, distributions, votes, priority, and financial obligations. Because of this, they fall under securities laws and require a carefully coordinated process involving legal structuring, compliance verification, identity management, token modeling, and issuance controls.

The Framework v3.5 provides issuers with a **clear, step-by-step pathway** from traditional financial structuring to compliant digital securities ready for distribution to qualified investors.

***

### **Security-Token Scope**

This framework applies **exclusively to security tokens**, meaning tokens that represent:

* equity or shares in a company
* units in an SPV or holding entity
* debt instruments or notes
* revenue-sharing or profit-interest instruments
* private fund interests or share classes
* tokenized corporate rights

Security tokens are financial securities, and therefore must operate under a robust, regulator-ready onboarding methodology.

#### **This framework does&#x20;*****not*****&#x20;apply to:**

* commodity-backed tokens
* asset-backed tokens (ABT)
* stable-value or treasury tokens
* carbon credits and ESG units
* utility tokens
* payment tokens
* hybrid programmable assets outside securities law

These other categories require **alternative tokenization frameworks**, different legal structures, and custom compliance pathways. Framework v3.5 is strictly for **regulated financial securities**.

***

### **Why a Dedicated Security Token Framework Is Required**

Security tokens are not created by simply deploying a smart contract. They require alignment of:

* corporate law
* securities law
* cross-border investor eligibility
* KYC/KYB identity validation
* custody and ownership documentation
* governance rights and obligations
* technical enforcement of restrictions
* investor disclosures and offering materials

Traditional finance would require transfer agents, custodians, administrators, and compliance officers.\
In tokenized finance, these responsibilities shift to:

* programmatic compliance systems (DID)
* programmable security logic (STV3)
* automated investor onboarding (Stobox 4)
* issuer governance modules

A structured onboarding process ensures issuers follow a legally defensible, regulator-ready path.

***

### **Stobox 4 as the Operational Environment**

Stobox 4 is the platform where all processes of the Onboarding Framework v3.5 take place.\
It serves as:

* the issuer portal
* the investor onboarding gateway
* the compliance and identity engine
* the documentation hub
* the STV3 integration interface
* the distribution and subscription management system

Security tokens created through Framework v3.5 can only be deployed and operated **within the Stobox 4 environment**, ensuring:

* uniform compliance
* correct use of Stobox DID
* validated investor participation
* structured issuance workflows
* standardized reporting for issuers and regulators

Stobox 4 acts as the operational foundation for tokenized securities, while STV3 provides the programmable logic on-chain.

***

### **STV3 Programmable Security Tokens**

Tokens created under Framework v3.5 utilize the **STV3 Protocol**, a programmable asset standard designed specifically for regulated financial instruments.

STV3 introduces:

* transfer restrictions
* cap table enforcement
* automated lockups and vesting
* distribution logic (dividends, coupons, revenue share)
* governance rights
* compliance validation at pre-transfer stage
* deterministic regulatory enforcement

These features transform a digital security into a **self-governing, compliance-native instrument**.\
The onboarding framework ensures these programmable rules reflect the issuer’s legal structure and regulatory obligations accurately.

***

### **The Importance of DID Identity in Securities Onboarding**

A foundational principle of security tokenization is that **every investor must be verified**, and **every wallet must correspond to a validated identity**.

Under Framework v3.5:

* all investors complete KYC/KYB
* Stobox DID is issued to store compliance attributes
* every investor action (subscription, transfer, redemption) is validated via DID
* illegal or unauthorized transactions are rejected automatically

This ensures the STO remains compliant at all times and in every jurisdiction.

***

### **Summary**

The **Stobox Tokenization Onboarding Framework v3.5** is the comprehensive, security-token-only methodology that enables issuers to launch compliant, programmable digital securities through Stobox 4. It establishes a rigorous, predictable, and regulator-aligned process that integrates legal, compliance, identity, and technical modeling.

Stobox Tokenization Onboarding Framework v3.5 guarantees that every digital security created through Stobox meets the highest standards of:

* legal enforceability
* operational transparency
* investor protection
* technical robustness
* compliance automation

This Introduction sets the foundation for the structured onboarding steps that follow.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stobox.io/tokenization_framework/introduction.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
