Regulatory Positioning · Request for Guidance

Regulatory Positioning

A functional description before legal qualification

This page describes the operational perimeter of the Osnias architecture and the intended roles of its tokens. It does not claim a universal legal classification. Regulatory treatment may differ by jurisdiction, activity, counterparties and implementation. Osnias intends to submit jurisdiction-specific requests for guidance to the relevant authorities.

No deposits No credit No leverage No traditional banking activity Clearing / custody separation Independent lending partners

What Osnias does — and what it does not do

The architecture is designed around a narrow functional distinction: governance, clearing and third-party lending are separate activities. The regulatory analysis should therefore begin from the actual function performed by each component rather than from the generic fact that blockchain tokens are used.

Clearing

Clearing & settlement

ORUSD and OEURO are designed as restricted clearing-register tokens used for direct settlement according to explicit protocol rules.

Governance

Token governance

OSNIAS is designed as a governance token with a distinct economic and voting function. Governance and clearing remain separate technical domains.

Lending

Independent partners

Lending, collateral custody, risk management and credit decisions remain within independent partner infrastructures.

Functional statement. Osnias Clearing does not collect customer deposits, does not issue credit, does not create leverage and does not operate a traditional banking balance-sheet activity.

Three tokens, three distinct functions

OSNIAS

Governance token. Fixed genesis supply, canonical governance state on Sei, EVM economic mobility and public technical documentation.

Governance
ORUSD

USD-denominated clearing-register token with restricted P2P circulation, explicit mint/burn, oracle attestation and manager-gated settlement.

USD clearing
OEURO

EUR-denominated clearing-register token with the same narrow clearing purpose and a distinct technical implementation and public audit reference.

EUR clearing
Important distinction. Shared use of blockchain infrastructure does not make these token classes economically identical. Governance rights, clearing representation and external lending services must be analyzed separately.

Operational responsibility by activity

Activity Osnias Clearing Independent partner / third party
Clearing-register logic Yes No
Token governance OSNIAS governance framework External integrations may exist but do not replace canonical governance
Customer deposits No Only if independently offered and legally authorized by a third party
Credit issuance No May be performed by independent lenders
Leverage No protocol leverage Third-party activity, if any, remains outside Osnias clearing rail
Collateral custody Not held by clearing-token contracts Independent partner responsibility
Risk underwriting No Independent lender responsibility
Clearing settlement Yes Partners may provide external evidence or instructions

Regulatory dialogue by authority

The same technical architecture can receive different legal treatment depending on jurisdiction. Osnias therefore intends to prepare a separate factual presentation and request for guidance for each relevant authority.

United States

Initial analysis to address securities, commodities, money transmission, custody and lending boundaries.

SEC / CFTC / FinCEN — planned

France

Initial analysis to address crypto-asset services, payment/banking boundaries, governance token treatment and clearing architecture.

AMF / ACPR — planned

European Union

Initial analysis to address MiCA perimeter, payment/e-money boundaries and the treatment of governance and restricted clearing tokens.

ESMA / EBA — planned

Switzerland

Initial analysis to address token classification, financial-market infrastructure, custody and lending boundaries.

FINMA — planned

Andorra

Initial analysis to address digital-asset, financial-services and local authorization perimeter.

AFA — planned

Other jurisdictions

Additional regulatory submissions may be prepared where partners, users or infrastructure deployments create a material nexus.

Open review

Request for guidance, not self-classification

The purpose of the regulatory workstream is to provide each authority with the same technical facts while allowing the legal analysis to remain jurisdiction-specific. The project should not rely on a single global statement that a token or service is “regulated” or “unregulated”.

What will be submitted

Factual technical package

  • Token purpose and functional perimeter.
  • Source code and ABI references.
  • White papers and audit-reference documents.
  • Testnet deployment references.
  • Governance and privileged-role architecture.
  • Clearing / custody / lending separation.
  • Zenodo DOI permanent archives.
What will be asked

Jurisdiction-specific questions

  • How should each token be classified in the jurisdiction?
  • Which activities, if any, require authorization or registration?
  • Does the clearing-register model fall within payment, e-money or another regulated perimeter?
  • What obligations arise from third-party lending integrations?
  • What AML/KYC obligations attach to the relevant actor and activity?
  • Which disclosures should accompany public or partner deployment?
Legal-positioning principle. Technical architecture is described as fact. Legal classification is requested from, or analyzed against, the applicable regulatory framework in each jurisdiction.

Public code, white papers and permanent archives

Regulatory dialogue is supported by the same public technical materials available to developers and auditors. Source code, ABI files, flattened contracts, white papers, testnet addresses and Zenodo archives are intended to be publicly referenced.

OSNIAS

Governance-token technical archive and source package.

DOI 10.5281/zenodo.22139986

ORUSD

USD-clearing-token technical archive and source package.

DOI 10.5281/zenodo.22140272

OEURO

EUR-clearing-token technical archive and source package.

DOI 10.5281/zenodo.22140908