The Asset Registry below is a live web tool: it builds real, hashed, verifiable Asset Passports today. Native token issuance, real lending and a financial marketplace activate at block #30,000 (automatic by height) but are admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE) with public access disabled — technical availability ≠ regulatory authorization. Examples use fictional assets. Not an offer of any financial product.
Know what an asset is before putting it on-chain. SOST turns any real or digital asset — real estate, mining, companies, commodities, art, vehicles, IP, contractual rights — into a verifiable digital record: it captures the evidence, records who declares each fact and whether it was independently verified, values it, defines the right a token represents, and seals it into an Asset Passport anchored on SOST. It does not decide the legal meaning, guarantee value, custody the asset, or enforce off-chain promises. SOST the coin keeps its supply and only pays fees.
Asset Registry — live webAny asset classSOST supply untouchedAsset Marketplace — activates #30,000 · admin-gated · public access disabled
Tokenization & Offers · one Passport, four ways to offer it
What do you want to do?
Every path starts from the same verifiable Asset (or Project) Passport. Tokenize is a live registry product today (mainnet anchor pending verification). Auction, Draw and Project Funding are engine-complete and lab-verified; mainnet execution is admin-gated (S14 RESTRICTED DEVELOPER MODE at consensus; public access disabled), and real-funds use stays disabled pending the applicable legal framework — nothing here changes SOST supply or consensus.
Tokenize
Divide a right into units.
CURRENT · Live registryMainnet anchor: pending verification · native assets: activate #30,000 (admin-gated)
Before any asset is tokenized on SOST. SOST approves and activates no tokenization request unless the applicant first presents the complete legal and technical documentation that applicable law requires for the specific class of asset being tokenized — including, as applicable, proof of title and ownership, independent valuation, the offering or prospectus documents, the required regulatory authorizations, and custody and audit evidence. That documentation must be made available publicly and transparently, so that any prospective holder can review it in full before acquiring or investing in any token that represents the asset. Technical availability on this network is never an offer, a solicitation, or a regulatory authorization, and SOST makes no determination as to the legal classification of any asset or token — LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
Regulatory requirements by jurisdiction
Regulatory information last reviewed: 2026-10-02 · INFORMATIONAL ORIENTATION · NOT LEGAL ADVICE
Continents below are navigation only — no continent has a single law. Each opens to the supranational framework(s) where they exist and the principal national regulators. For any asset the relevant requirements depend on the asset, the rights the token represents, the issuer, the investors and where it is offered.
TYPICAL AREAS TO VERIFY (may apply depending on asset / structure / rights / offering / investor location)
Jurisdiction-specific requirements apply. These summaries are high-level regulatory orientation only and do not constitute legal advice or a complete statement of applicable law. National, regional, state/provincial, sector-specific and asset-specific rules may impose additional requirements depending on the asset, token rights, issuer, investors, offering structure, custody model and place of distribution. Where requirements overlap, the stricter or additionally applicable obligations may need to be satisfied. The applicant is responsible for obtaining appropriate professional advice and satisfying every applicable requirement before SOST will consider activation.
Technical eligibility does not imply legal eligibility. · LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
Europe
European Union / EEA · Frameworks: MiCA (crypto-assets) · MiFID II / Prospectus Regulation (financial instruments) · AMLD (KYC/AML), applied by each national competent authority. Regulators: ESMA, EBA
United Kingdom · FCA · FSMA, cryptoasset financial-promotion regime
Official sources link to each competent regulator. SOST is not a legal adviser and not a regulatory authority; this section is orientation to help an applicant engage qualified counsel and the relevant regulator. LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
Verification · PROFESSIONAL ATTESTATION
Professional Attestation
How the tokenization layer satisfies real-world requirements without SOST ever certifying legality. SOST verifies, cryptographically, that a named professional issued a specific opinion over specific documents — it does not judge whether that opinion is correct, and it never certifies that an asset or offer is legal. The requirements are dynamic: they change with the modality, the asset class and the jurisdiction, so you only ever provide what your specific case needs.
Status. This describes the verification model for the native-asset / tokenization layer, which activates at block #30,000 (automatic by height) and is admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE) with public access disabled. It is a description of requirements, not a live public service. LEGAL CLASSIFICATION IS NOT DETERMINED BY SOST.
✓ WHAT SOST VERIFIES (cryptographically)
“This identified professional has issued this opinion on these documents, in this jurisdiction, on this date.”
the signature is valid and who issued it;
the issuer’s professional credential — professional_registry, credential_id, jurisdiction — checked against the official registry where possible (credential_checked_at);
it corresponds to the exact document (hash match);
the document has not changed since;
it is not expired, and its lifecycle status is still ACTIVE (not SUPERSEDED / REVOKED / EXPIRED);
the platform’s internal requirements for that case are met.
⚠ WHAT SOST NEVER DOES
It does not certify that an asset or offer is legal.
It does not decide that the professional’s opinion is correct.
It does not custody, collect or distribute the expert’s fee.
It does not determine the regulatory classification of the token.
Who pays the expert — and how. The applicant pays their own lawyer / appraiser / auditor directly, exactly as they would for any business operation. SOST does not custody or distribute those fees. You may bring your own expert (you already have a lawyer? perfect — you are not required to use a “SOST” one). SOST may later publish a list of professionals who accept this kind of work, but even then the expert invoices the client, and payment (EUR, USDC, SOST or another agreed means) is arranged directly between them — the protocol does not participate in it.
Three levels — use only the one your case needs
1 · AUTOMATIC ONLY
For anything a machine can prove: hashes, signatures, technical identity, Passport consistency, dates, documents present, correct contract, supply. No human needed.
2 · EXPERT
When rights or law must be interpreted: equity, debt, real-estate investment, revenue rights, certain public offers. A signed professional opinion is required.
3 · SPECIALIST
Added only when the asset demands it: an appraiser for real estate, an auditor/custodian for gold, an IP specialist for certain rights, etc.
No “three validators must vote” scheme — that adds cost with no benefit. One verification infrastructure, dynamic requirements.
INITIAL ATTESTATION TYPES
LEGALOWNERSHIPVALUATION
The system decides automatically which of these it needs from asset class + jurisdiction. More specialist types can be added later; these three cover the common cases.
SOST always checks automatically: documents present, hashes, signatures, that nothing was modified, dates/expirations, who submitted it, declared jurisdiction, and version history. Only after this comes the part that changes per modality.
Requirements vary by modality
Modality
Expert likely?
What is checked
Tokenize
Yes, frequently
Ownership of the asset, the rights the token represents, legal structure, valuation where relevant. Typically Ownership + Legal (+ Valuation).
Auction
Depends on the asset
That the seller may dispose of the asset and remains authorised to sell; sale conditions; auction-specific rules. If the asset is an already-verified SOST asset, existing Passport evidence may be reused — but only after SOST automatically re-checks that those attestations are still valid and that owner, asset, jurisdiction and transfer rights are unchanged; otherwise a fresh attestation is required. Only the auction terms are genuinely new.
Project Funding
Usually yes
Who receives the money, what rights the funder obtains, conditions, risks, refunds, possible consideration as investment/security. Typically Legal + corporate/issuer verification — an appraiser is usually not needed.
Draw
Depends on jurisdiction
Legality of the raffle/draw in the jurisdiction, permits/licences if applicable, rules, prize, eligibility, selection mechanism, result transparency. Typically Legal/regulatory + prize ownership + draw rules; kept restricted until each jurisdiction is clear.
Orientation, not a universal rule. The table above is typical guidance. For every case the engine resolves each requirement as REQUIRED / OPTIONAL / NOT REQUIRED from the specific jurisdiction + structure — e.g. a Draw is not hard-coded as “expert always required”; it is resolved per jurisdiction. A single person or organization may issue more than one attestation type (e.g. LEGAL and OWNERSHIP) only if they hold the appropriate credential for each — never forced to hire three different people artificially.
DRAW
Legal / regulatory REQUIRED
Prize ownership ... REQUIRED
Valuation ......... USUALLY NOT
Draw rules ........ REQUIRED
Attestations are reusable while valid. If a property already has verified ownership, a current valuation, a legal opinion and an Asset Passport, you do not pay three professionals again each time it is used (e.g. in an Auction). The evidence is reused, and a new attestation is requested only when it expires, or when the asset, the owner, the jurisdiction or the legal structure changes materially. One verification infrastructure; dynamic requirements per modality + asset + jurisdiction — so tokenization does not become a bureaucracy.
HOW THE PROTOCOL REGISTRY RECORDS IT
ATTESTATION TYPE : LEGAL REVIEW
ISSUER : Law Firm X / Lawyer Y
PROFESSIONAL REGISTRY : national bar / official registry
CREDENTIAL ID : <registry / bar number>
CREDENTIAL CHECKED AT : 2026-10-03 (against the registry, where possible)
JURISDICTION : Spain / EU
SCOPE : Tokenization structure
DOCUMENT HASH : abc123…
ISSUED / EXPIRES : 2026-10-03 / 2027-10-03
SIGNATURE : VALID
STATUS : ACTIVE (ACTIVE / SUPERSEDED / REVOKED / EXPIRED)
RECORD : PROFESSIONAL ATTESTATION PROVIDED
Never recorded: “SOST CERTIFIES THIS IS LEGAL” — SOST records that an identified professional provided an attestation; it does not endorse its conclusion.
Lifecycle & revocation. Every attestation carries issued_at, expires_at and a status (ACTIVE / SUPERSEDED / REVOKED / EXPIRED) — a lawyer may withdraw an opinion, an appraiser may correct a valuation, an authorisation may lapse. A superseded or revoked attestation is never deleted: the history is append-only, so the record always shows exactly what was relied on, by whom, and when.
Why a professional opinion can matter (EU example). Classification depends on the specific rights the token represents and is assessed case by case (CNMV). Importantly, tokens that qualify as financial instruments fall outside MiCA and come under the existing financial-services framework — which is exactly why, for certain real tokenizations (equity, debt, investment rights, some real-estate structures), a signed professional opinion is appropriate before activation. References:
CNMV — Informe sobre activos digitales ·
EUR-Lex — MiCA Regulation (EU) 2023/1114.
This is informational orientation, not legal advice, and does not determine the classification of any token.
V1 scope — deliberately out, for now. Professional Attestation V1 intentionally does not include expert reputation, expert staking, rewards, validator consensus, or a fee marketplace. Those are added only if and when real tokenization volume justifies them. V1 is just: require the right attestations, verify them cryptographically, record their lifecycle.
V1 model. The applicant pays their own experts; SOST neither custodies nor distributes their fees; SOST only requires and cryptographically verifies the attestations a given case needs. No validator network, no in-house legal team, no fixed cost for the protocol — one verification infrastructure with dynamic, reusable requirements.
Asset Registry · CURRENT PRODUCT
SOST Asset Registry
A registry turns an asset into a verifiable record. You describe the asset and the right a token represents; the Registry records every material statement together with who said it, the evidence behind it, and whether it was independently verified, then seals the whole record with a fingerprint (manifestHash) that anyone can re-check and that can be anchored on the SOST chain. SOST proves the record's integrity and existence in time — never that a claim is legally true.
Everything up to and including Asset Passport + Verification works on the web now. Anchor is prepared (anchor-ready doc_ref) and has been verified on a development chain; a mainnet anchor will be shown only when demonstrated on mainnet.
Every statement is a Claim
In the Registry each material fact is a claim that answers six plain questions — so nobody has to trust a bare number:
SOST Asset Marketplace. Financial issuance, secondary trading, distribution of returns, custody, regulated settlement and native on-chain assets. These activate at block #30,000 (automatic by height) but are admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE) with public access disabled, and never shown here as a product. Technical availability ≠ regulatory authorization.
current product vs future protocol
The full process is explained below (see How it works). Creating, issuing or transferring an asset is an operational action that runs in the authenticated dashboard. The advanced Tokenization Studio and per-engine demos remain further down for power users.
Create · Register → Verify → Tokenize
Create an Asset Passport
The wizard walks through Asset → Right → Units → Review → Execute (the full flow is explained in How it works). You supply the facts; SOST assembles the claims, provenance, valuation, canonical hash and Passport underneath — automatically. Nothing on this page is a market quote, a legal opinion or an offer.
Operational action · authenticated dashboard
Creating, issuing, transferring or burning an asset is an operational action — it runs in the authenticated dashboard and is enforced by the consensus admin gate (S14 RESTRICTED DEVELOPER MODE; public access disabled). Native assets, tokenization and the DEX activate automatically at block #30,000; real-funds use stays disabled pending the applicable legal framework. LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
One Asset (or Project) Passport, four ways to bring it to people. Only Tokenize is a current product; the others are future/regulated modules — built and demoable here, never operated on real funds until a legal framework exists.
Recoverable escrow + bids; the highest valid bid wins. No chance involved — legally simpler than a draw, but asset-transfer / AML / tax rules still apply.
Tickets cover a minimum price; when sold out, a verifiable draw adjudicates the asset. In Spain this is a rifa (DGOJ / Ley 13/2011), not an auction — requires authorisation; disabled for real use.
Fund something not built yet: fund → build → verify → deliver, released by milestones. Debt/revenue/equity offers may be regulated crowdfunding (ECSPR / CNMV PSFP, ≤ €5M).
fund → build → deliver
Draw & Project Funding: LAUNCH DISABLED — demo only, no real funds
Highest valid signed bid wins (ties → earliest; no chance). Bidders post a refundable escrow (a reference value → SOST quote, not custodied fiat); losers are refundable, the winner settles. Real funds disabled.
Auction result and payment settlement are separate; SOST does not custody external funds. Legal: asset-sale / contract / AML / tax rules apply. REAL FUNDS EXECUTION DISABLED — engine + demo only.
Verifiable Draw — demo · FUTURE / REGULATED
Reuses the DTD philosophy (commit-then-reveal; nobody can pick the winner after the seed is known) as an application-layer engine — it does not touch the DTD jackpot or consensus.
20 USDC is a reference value, not custodied USDC — it is converted to an equivalent SOST quote at entry (oracle reference), so the number of tickets needed to cover the seller's minimum is fixed in reference terms regardless of SOST's price. Escrow of that SOST is refundable while the campaign is open and if it never sells out. Open design point (to fix before any real use): who bears the SOST price variation between a participant's entry and campaign close — participant, a stable-reference rail, or a hedging rule. Not decided; not operated on real funds.
While the project doesn't exist yet it carries a Project Passport; when it is built and operating, that becomes an Asset Passport — one continuous record: IDEA → FUNDING → CONSTRUCTION → OPERATION → ASSET. You don't tokenize a plant that doesn't exist — you tokenize a right tied to the project. All-or-nothing funding, milestone-gated releases, honest escrow accounting.
Funds release per verified milestone, never all up front; if the minimum isn't reached by the deadline, everyone is refunded. Offering debt/yield/equity may be a financial instrument or regulated crowdfunding — LEGAL CLASSIFICATION: NOT DETERMINED BY SOST; launch stays disabled until an authorised partner/framework is in place.
What is live today
Tokenize · Auction · Draw · Project Funding — one Asset (or Project) Passport, four ways to offer it. Below is exactly what works now, what is engine-complete/lab-verified behind a gated mainnet path, and and what activates at #30,000 behind the admin gate (S14, public access disabled). Nothing here changes SOST supply or consensus.
● Available now
Asset Passport — build a structured claim for any asset
Complete on-chain Asset Passport round-trip — manifest hash → signed capsule tx → node acceptance → mined block → confirmation → read-back → hash match → tamper test
Until proven, a passport shows ANCHOR READY — never “anchored”.
◆ Native-asset layer · activates at #30,000
Native asset genesis / issue
Native transfer / burn / reissue
Consensus module activates at block #30,000 (automatic by height), admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE); public access disabled.
The building blocks
Four components today, plus a future consensus module. Each is honest about what it proves.
Asset Passport
A canonical, hashed record of an asset built from typed claims — identity, ownership declaration, valuation, structured rights, documents (each SHA-256'd), settlement reference — each carrying its own provenance and verification status. Sealed into a reproducible manifestHash and anchored on SOST via a Capsule doc_ref — no consensus change.
claims v2 · provenance · live-capable
Asset Intelligence
A modular, fully-traceable valuation engine: classification → evidence quality → per-category model → range → haircuts → confidence → suggested LTV. Every figure carries its rule and inputs. No opaque AI.
deterministic · traceable
Asset Finance
A voluntary lending simulator: bilateral / multi-lender / pool structures with default and liquidation waterfalls. A hard invariant proves no SOST is ever minted. No real loans, no fund-raising.
simulation only
Native UTXO assets
A consensus module that activates at #30,000 (admin-gated via S14, public access disabled) for issuing/transferring/burning assets natively on the SOST UTXO ledger, with immutable genesis policy and per-asset supply accounting. Gated behind adversarial tests, devnet, audit and a coordinated upgrade — not part of the current hard fork.
specification · future
Tokenization
Tokenize — how an asset becomes tokens
The core rule: an asset's value comes from its own economic reality — never from SOST's supply. SOST is the gas, the unit of exchange and the settlement asset; its supply is untouched. Everything below is a planning model (PREVIEW): no native token is minted yet.
Asset value ≠ token supply
Two independent numbers. Value is what the asset is worth (from comparables, evidence, income, risk, liquidity). Supply is how many tokens you choose to divide it into. Never derive one from SOST's supply — that would mix two economies.
first principle
SOST has three roles
1 · Gas — pays for emission, transfer and registry ops. 2 · Unit of exchange — token prices are quoted and settled in SOST. 3 · Settlement — the liquidation asset. It is never collateral and is never minted to back anything.
gas · exchange · settlement
Supply stays fixed
Each asset gets its own token supply. SOST keeps its protocol supply intact. When SOST's market price moves, the number of the asset's tokens does not change — only how many SOST are needed to buy them.
tokenomics safe
Universal Asset Valuation Engine
data→evidence→asset-specific model→comparables→adjustments→risk→liquidity→valuation range + confidence
Not an "AI that says what it's worth" — a deterministic, fully-traceable architecture. It never reads SOST's supply as an input; SOST only enters at the final conversion step.
The three formulas
Vasset = f( data, market, evidence, risk, liquidity ) // from the asset's own reality
Supplyasset = g( Vasset, granularity ) // how many tokens you divide it into
Pricetoken in SOST = ( Vasset / Supplyasset ) / PriceSOST // the only place SOST enters
Suggested granularity
The engine proposes a supply that yields a comfortable trading unit. You can always override it.
Asset value
Suggested supply
Initial reference
€10,000
10,000 tokens
≈ 1 / token
€250,000
250,000 tokens
≈ 1 / token
€3,500,000
3,500,000 tokens
≈ 1 / token
€500,000,000
50,000,000 tokens
≈ 10 / token
Creating tokens is not enough — what does each token represent?
A token is only meaningful if the right behind it is stated. The Registry makes you declare a right type and records the facts around it:
It then records, as facts: economic rights declared, obligor identified, agreement attached, agreement hash and independent verification. What it never does: LEGAL CLASSIFICATION — NOT DETERMINED BY SOST. Whether a declared right is a security or financial instrument (MiCA / MiFID II) is for the issuer and their advisers to determine.
rights · facts, not legal opinion
Tokenization Studio · PREVIEW / PLANNING
Enter an asset value and see the full proposal: valuation, recommended supply, and the price in SOST. Nothing is minted or traded — this is a planning calculator.
The SOST price is an illustrative assumption you type in — it is not a live market quote and SOST is not yet listed. The valuation figures are a deterministic demo, not a professional appraisal. No tokens are created and no order is placed.
SOST Asset Registry — generate a Passport (v2)· CURRENT PRODUCT
Turns the Studio into a real Asset Passport v2: a set of typed claims (valuation, right, ownership, settlement) each carrying its own provenance + verification status, canonicalized to a deterministic manifestHash ready to anchor on SOST. It records facts — it never classifies the token legally.
Asset Registry — CURRENT PRODUCTAsset Marketplace — FUTURE (no order book, custody, secondary trading or fiat settlement)
Facts only. SOST does not determine the legal or regulatory classification of the asset or token. Declaration ≠ legal title · on-chain anchor ≠ truth of the claim · token ≠ ownership unless legally constituted · valuation ≠ market price · tokenization ≠ investment offer. If a declared right may fall under MiCA / MiFID II / securities law, that is for the issuer and their advisers to determine.
Worked example
A machine is valued at €100,000. The owner tokenizes it into 100,000 tokens, so 1 token = 0.001% of the asset and the initial reference is 1 €/token.
If 1 SOST = €0.12, buying €1,000 of tokens costs ≈ 8,333 SOST (1,000 / 0.12).
If tomorrow 1 SOST = €0.20, the same €1,000 of tokens costs 5,000 SOST. The token count never changed — only how many SOST are needed to buy them. SOST supply is untouched throughout.
Asset Passport — try it
Build a passport for a fictional asset. Anchoring a manifest hash proves a document set existed at a time — it is NOT proof of ownership, authenticity or any legal right.
This form builds a V1 passport. The newer V2 model (used by the Asset Registry above) adds typed claims, per-claim provenance and verification. V1 passports are never rewritten: they keep their original manifestHash and still verify exactly — V2 simply reads them through a normalized claims view. Neither is obsolete; V2 is the current format for new records.
Asset Intelligence — try it
A traceable valuation of a fictional 1 kg gold bar. Every number below is produced by an explicit rule over the inputs — expand the trace.
Asset Finance — simulator
A voluntary loan against the asset above, purely simulated. The conservation check proves money to lenders only ever comes from borrower payments + collateral — no SOST is minted, no reserves used.
Simulation only. Token collateral is a claim on an off-chain asset, not enforceable physical collateral. This does not raise funds, offer loans, or promise returns.
Sell an Asset Passport to the highest valid bidder. Signed bids, refundable escrow, reserve, anti-sniping and settlement — the full state machine on the lab-verified engine. Toggle Advanced for signed-bid digests, escrow states and raw state. Real funds are disabled behind the regulatory gate.
Running an auction is an operational action — it runs in the authenticated dashboard, behind the consensus admin gate (S14; public access disabled). Real funds stay disabled pending the applicable legal framework.
Allocate an Asset Passport through a verifiable draw: sell tickets to a target, freeze the campaign into a campaignHash, seed the winner from a future SOST block hash, and let anyone recompute the result. Toggle Advanced for the seed, ticket-list hash and raw state. Real funds are disabled; DTD consensus is untouched.
Running a verifiable draw is an operational action — it runs in the authenticated dashboard, behind the consensus admin gate (S14; public access disabled). Real funds stay disabled; DTD consensus is untouched.
Fund something that does not exist yet. All-or-nothing window, milestone-gated ordered releases, integer-safe accounting, and a Project Passport that becomes an Asset Passport on delivery. Toggle Advanced for raw accounting/state. Real funds are disabled behind the regulatory gate.
Running a project-funding campaign is an operational action — it runs in the authenticated dashboard, behind the consensus admin gate (S14; public access disabled). Real funds stay disabled pending the applicable legal framework.
Five simple stages. You never see claims, JSON or hashing unless you open the technical details.
1 · Define the asset
Say what it is, who owns it, its jurisdiction and a reference value — and attach any evidence (reports, registry references, documents).
asset
2 · Define the right
Say what each token represents: a certificate, usage, revenue share, sale proceeds, debt, ownership, a royalty, or a custom right — with obligor and agreement where relevant.
right
3 · Divide into units
Choose how many token units the right is split into. Units are their own thing, not fractions of SOST; the SOST price never changes their number.
token
4 · Build the Passport
SOST assembles claims, provenance, verification, valuation and a canonical manifestHash automatically, and runs a legal-readiness check (informational, not legal advice).
passport
5 · Anchor & verify on SOST
The Passport hash can be anchored on SOST as tamper-evident, timestamped proof it existed — and re-verified by anyone. SOST does not decide legal truth.
sost
Pipeline: ASSET → RIGHT → TOKEN → ASSET PASSPORT → SOST. The owner supplies the facts; SOST records who declared each one; independent sources can verify them later.
Scope
What can be tokenized?
Technically, a very broad range of identifiable assets and rights can be represented. Legally, not every asset or right can be freely issued, transferred or offered to the public — that depends on the right, the jurisdiction and the regulatory classification.
Category
Examples
What the token may represent
Legal complexity
SOST status
Physical assets
Real estate, mines, machinery, art
Ownership / use / revenue / sale proceeds
Structure-dependent
Registry supported
Debt
Loans, receivables, bonds / notes
Repayment + coupon
Regulated review likely
Registry supported · regulated issuance future
Equity
Company shares / interests
Ownership / economic / voting
Regulated review likely
Registry supported · regulated issuance future
Commodities
Gold, metals, inventory
Ownership / claim / redemption
Structure-dependent
Registry supported
IP / royalties
Patents, music, licences
Royalty / use rights
Structure-dependent
Registry supported
Certificates
Authenticity, records, warranties
Evidence / certificate
Lower in many cases
Registry supported
"Legal complexity" is descriptive orientation, not legal advice: Lower · Structure-dependent · Regulated-review likely. A very broad range can be represented; SOST does not make any issuance lawful.
Can everything be tokenized? Technically, most identifiable assets/rights can be represented. Legally, issuance/transfer/public offering requires: an identifiable asset/right · authority of the issuer/owner · a legally definable right · evidence · transferability where required · the applicable jurisdiction · regulatory review when applicable. SOST never claims you can "tokenize literally anything".
Legal & regulatory readiness
What SOST does — and does not — do
SOST does
Anchors Asset Passport hashes · provides immutable timestamp / integrity evidence · proves the Passport has not changed · can provide network utility / fees · can support settlement where technically and economically viable.
SOST does NOT automatically
Prove legal ownership · validate every owner declaration · guarantee valuation · guarantee liquidity · make a financial offering lawful · custody external funds · determine legal or regulatory classification.
Future regulated layer — direction, not a claim of authorisation
Informational overview as of 2026-10-02; not legal advice. Requirements depend on the legal classification and jurisdiction.
If the token is NOT a financial instrument
It may fall under MiCA or other regimes depending on its characteristics.
If the token IS a financial instrument
MiCA is not the applicable regime for the instrument itself; MiFID II / securities-markets law and national rules apply. ESMA classifies by the rights actually attached, case by case — the label or technology does not change the substance.
Spain — Ley 6/2023
Allows negotiable securities to be represented via DLT systems under its conditions (system integrity, identification of holders and of the nature/number of the securities, an issuance document, and administration of the register). SOST does not meet these today and is not authorised to issue securities — this only sets the architectural direction.
EU DLT Pilot Regime
A framework for certain DLT market infrastructures dealing with financial instruments. It belongs to the future SOST Asset Marketplace / regulated infrastructure — SOST is not currently authorised under it.
Future compliance module · NOT ENABLED
Identity · KYC · AML · investor eligibility · jurisdiction · whitelist · transfer restrictions · holding limits · corporate actions · freeze / recovery · ownership register. Architecturally prepared; none of it is active today, and no fake controls are shown as functional.
Before any asset is tokenized on SOST. SOST approves and activates no tokenization request unless the applicant first presents the complete legal and technical documentation that applicable law requires for the specific class of asset being tokenized — including, as applicable, proof of title and ownership, independent valuation, the offering or prospectus documents, the required regulatory authorizations, and custody and audit evidence. That documentation must be made available publicly and transparently, so that any prospective holder can review it in full before acquiring or investing in any token that represents the asset. Technical availability on this network is never an offer, a solicitation, or a regulatory authorization, and SOST makes no determination as to the legal classification of any asset or token — LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
SOST's role
Does the SOST price change the number of token units? No.
The units of an asset are independent of the SOST price. SOST is the network that registers, verifies and (where liquidity exists) settles them — not the asset itself.
1,000,000 SIERRA-X stay 1,000,000 SIERRA-X whether 1 SOST = €0.001 or €10. The SOST price only matters when SOST is used for fees, settlement or as a reference — never to define how many units an asset has.
A token unit is not a fraction of SOST: all SOST are fungible, so a colored/native-asset layer is needed to tag units on-chain. That SOST Native Assets layer activates at block #30,000 (automatic by height) but is admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE) with public access disabled — technical availability ≠ regulatory authorization, and it is never operated near a consensus fork.
valuation ≠ token supply ≠ SOST price ≠ liquidity
Loading comparison…
Boundaries & honesty
What SOST does
Proves the issuer, the rules, the unit count, control and the history of a registered claim. Anchors document hashes. Runs transparent valuation and simulation.
What it does NOT do
It does not certify off-chain truth, guarantee value, custody your asset, make a token proof of ownership, or (today) issue native assets or provide real loans.
Separation
SOST Universal Assets is a general-purpose layer. GeaSpirit is a completely separate project and is not part of this platform.