← Back to the demo

Whitepaper figures

Every placeholder in the document, closed

The RETS whitepaper contains thirty-three [Insert Image Placeholder] notes. This page resolves all of them: conceptual flows are drawn as SVG diagrams in the demo's visual language, and figures that show the product itself are taken from the working screens. Each figure carries the section and the exact placeholder title it belongs to.

Chapter 2 · Token architecture

Token models on Mintlayer

§2.4 · Fungible Token Model Diagram

One asset, identical divisible units

A single property or portfolio is represented by a fixed supply of identical MLS01 tokens. Every holder owns the same instrument; economics are strictly pro-rata to the count held.

Also covers §7.1 · Single Unit Fractionalization Diagram

Asset Property or portfolio FT · MLS01 Fixed supply of 1,000,000 identical tokens at $1 Investor A 18,400 tokens · 1.84% Investor B 5,020 tokens · 0.50% … 148 more 150 investors, all KYC-verified

§2.4 · Non-Fungible Token Unit-Level Diagram

Unique tokens bound to identified units

Each unit of the building becomes its own MLS03 token carrying unit-level metadata — floor, size, rights. Ownership maps to a specific, identifiable piece of the asset rather than a share of a pool.

Also covers §7.2 · Multi Unit NFT Tokenization Diagram

Building Identified units Unit 402 · NFT MLS03 · 87 sqm · floor 4 Unit 403 · NFT MLS03 · 92 sqm · floor 4 Unit 404 · NFT MLS03 · defined fraction Direct owner One verified investor per unit

§2.4 · Compliance Integration Flow

Compliance is bound to the token, not bolted on

Both token standards route every mint and transfer through the same compliance engine: the KYC registry and the offering's rules sit between any two wallets, whatever the token model.

FT · MLS01 mint / transfer NFT · MLS03 mint / transfer Compliance engine KYC registry · eligibility rules lock-ups · caps · jurisdictions Verified wallet KYC-bound delivery

§2.4 · FT vs NFT Decision Flow

Choosing the token standard

The configurator's first question. Broad fractional participation with many investors points to FT; identified units or high-value allocations tied to a specific piece of the asset point to NFT.

New offering Structure to decide What does one token represent? an equal share of the whole an identified unit or fraction FT · MLS01 Many investors, frequent subscriptions NFT · MLS03 Unit-level ownership, unique rights

Chapter 3 · Lifecycle of a tokenized asset

Issuance, distribution, management

§3.1 · Smart Contract Deployment Flow

From asset record to on-chain deployment

The operator never touches blockchain tooling: the asset profile is hashed, the token configuration is validated, and the platform deploys the result to Mintlayer with the rules baked in.

Asset record Documents hashed and timestamped Configuration FT/NFT, supply, price, lock-ups, restrictions Deployment Generated and submitted by the platform Live on Mintlayer Rules enforced on-chain, tamper-resistant

§3.2.2 · Bitcoin Payment and On-Chain Compliance Flow

Digital-asset payments are screened before allocation

An incoming Bitcoin (or other digital-asset) payment is monitored, screened through Chainalysis-integrated tools, and only after the source of funds is cleared does the platform reconcile it with the subscription and release the tokens.

BTC payment Incoming transaction On-chain screening Chainalysis: source of funds, sanctions, illicit exposure Reconciled Matched to subscription · tokens allocated Manual review Held until the operator clears it

§3.2.2 · Multi-Method Payment Overview

Four rails, one reconciliation point

Whatever the investor pays with, every flow converges on the same reconciliation step: settlement confirmed, transaction linked to the right investor, allocation triggered only after validation.

ML · Mintlayer Native settlement Bitcoin Chainalysis-screened Bank transfer Matched to the order Card payment Single-session retail Reconciliation Settlement confirmed, linked to the investor's subscription Allocation Tokens to the verified wallet

§3.2.4 · KYC-to-KYC Transfer Flow

The multisignature gate on every transfer

Transfers are never executed automatically: the investor's signature alone is not a valid transaction. The compliance key co-signs only when both parties hold valid verification and every offering rule passes — otherwise nothing reaches the chain. Either way, the request lands in the audit log.

Also covers §4.2 · Multisignature Transfer Approval Flow and §8.3 · Multisignature Compliance Flow

Transfer request Investor key Compliance key Compliance gate 2-of-2 signature Settled Mintlayer UTXO Blocked No on-chain action Audit log update Sender, recipient, decision, signatures and timestamp — recorded for every request, approved or blocked

§3.2.4 · Transfer Restriction Diagram

Every configured rule, checked per transfer

Before the compliance key even sees a request, the engine evaluates the restrictions defined at issuance. Any single failure blocks the transfer outright.

Transfer request Sender → recipient Rule evaluation · Holding period / lock-up expired · Recipient KYC valid and eligible · Ownership cap not exceeded · Jurisdiction permitted · Investor category allowed Defined at issuance, enforced automatically All pass On to the compliance key Any failure Blocked, operator informed

§3.3.1 · Reporting Dashboard

The operator's reporting layer, as built

This placeholder shows the product, not a concept — so the figure is the working screen: capital raised, activation, volumes and unit economics across the platform.

Also covers §7.4 · KPI Dashboard Overview

KPI dashboard with platform metrics admin-kpi-dashboardOpen the live screen →

§3.3.2 · Yield Calculation and Distribution Flow

One click from distributable amount to receipts

The operator inputs the total; the platform calculates each holder's pro-rata share, validates compliance standing, executes the payout and generates downloadable receipts — automatically.

Amount in $524,300 distributable for the quarter Calculation Pro-rata per token, or per NFT economic rights Validation Accounts in good standing, compliance rules satisfied Payout 312 holders paid, receipts generated for each

§3.3.2 · Investor Yield History Panel

The investor's side of the same distribution

Every payout lands in the investor's history with the period covered and the calculation basis — the transparency half of the flow above.

Investor yield history with calculation basis investor-yield-historyOpen the live screen →

§3.3.3 · Announcement Center

Operator communications with a permanent record

Admin announcement composer admin-announcement-centerOpen the live screen →

§3.3.3 · Redemption or Buyback Workflow

Offer, acceptance, settlement, cancellation

The whitepaper's corporate-action flow as a figure. The demo screens for redemption remain in the backlog pending feedback; the concept itself is straightforward to document.

Offer Terms per the rules defined at issuance Notification All eligible investors, acceptance tracked Settlement Funds move under the compliance framework Cancellation Redeemed tokens burned, registry updated

Chapters 4–5 · Compliance & security framework

Verification, interventions, custody, audit

§4.1 · KYC and AML Compliance Flow

From applicant to verified investor — and onward

Verification is not a one-time gate: after approval the investor stays under ongoing monitoring, and a change in risk status routes them back to review.

Applicant Account created Verification checks · Identity and document integrity · Proof of residence · Sanctions and PEP screening · AML risk assessment SDD / CDD / EDD per the offering's rules Officer Approve / reject Verified Portal unlocked ongoing monitoring · re-screening · periodic review

§4.2 · Legal Intervention and Freeze Logic

The compliance key as the instrument of last resort

Disputes, court orders and fraud investigations all reach the asset through one controlled path: the compliance key suspends transferability at the right scope, and every step lands in the audit log with officer, rationale and time.

Dispute Injunction, contested estate Court order Seizure, mandated transfer Investigation Fraud, regulatory hold Compliance key Suspends transferability at the chosen scope Specific tokens One holding frozen Specific investor All positions frozen Entire project Offering-wide hold Every intervention recorded: reason, approving officer, time of execution · lifted when resolved

§4.4 · Wallet Architecture Overview

Three custody models, one compliance perimeter

Self-custody is the primary model — every wallet passes KYC before it can hold tokens. Regulated custody slots in where jurisdictions demand it, and the operator's own treasury runs on multisignature.

Non-custodial Investor holds the keys — Mojito, hardware wallets Primary model · KYC-bound Custodial Regulated third-party provider, unified platform interface Institutions · regulated offerings Treasury Operator funds under multisig: finance + compliance + audit Redemptions, buybacks, freezes Mintlayer Every wallet KYC-verified before it can receive tokens

§4.5 · Role Based Access Diagram

Segregation of duties, as configured in the product

The permission matrix screen documents the model better than an abstract diagram would: five roles, granular rights, no overlap between issuing, approving and paying.

Also covers §5.3 · Role Based Access Matrix

Role and permission matrix role-permission-matrixOpen the live screen →

§4.5 · Security and Auditability Overview

Four guarantees behind every action

Access is role-scoped, ownership lives on an immutable chain, every platform event is logged and attributable, and the infrastructure is built to stay up — together they make the platform auditable end to end.

Access control Role-based permissions, segregation of duties Immutability Ownership and transfers recorded on Mintlayer Action logs Every event time-stamped and attributed Availability Redundancy, failover, continuous monitoring Audit package on demand

§5.1 · Whitelabel Branding Configuration

The operator's brand, configured in one place

Logo, palette and custom domain on the left; a live preview of the investor portal on the right. The Acme Capital portal elsewhere in this demo is the output of exactly this screen.

Branding configuration with logo, palette, domain and live preview admin-branding-settingsOpen the live screen →

Chapter 6 · Platform features

The product, standing in for its own figures

§6.1 · Registration and Compliance Workflow

The onboarding wizard, mid-verification

Investor onboarding wizard with verification steps investor-onboardingOpen the live screen →

§6.2 · Token Structure and Supply Configuration

The issuance form: property intake, FT/NFT, supply, rules

Tokenization creation form admin-create-tokenizationOpen the live screen →

§6.2 · Compliance, Vesting, and Redemption Configuration Flow

The rules console: eligibility, due diligence, transfer controls

Compliance rules configuration compliance-rulesOpen the live screen →

§6.4 · Notification Flow Diagram

One event, every channel, a permanent record

Platform events fan out to the investor's dashboard and inbox, and each notice is stored in the project history — investors can always reconstruct what they were told, and when.

Event Distribution, new document, announcement, KYC expiring Notification engine Audience by project and role Dashboard Announcement center Email Under the operator's brand Project history Permanent, auditable

Chapter 7 · Use cases

Structures the same primitives can carry

§7.3 · Tokenized Fund Structure Diagram

Many assets, one fund token

A diversified pool wraps several properties into a single FT offering: investors hold fund tokens, and the yield of the whole portfolio flows through one distribution mechanism.

§7.1 and §7.2 are covered by the token-model figures in Chapter 2

Office asset Manhattan Tower Logistics asset Sunrise Hub Residential asset Harborview Fund · FT MLS01 One supply over the pool, NAV tracked per token Fund investors Pooled yield, one distribution mechanism

Chapter 8 · Technical architecture

What lives on-chain, what runs off-chain

§8.1 · On Chain Components Diagram

Everything Mintlayer is asked to guarantee

Mintlayer Token standards MLS01 fungible, MLS03 non-fungible Multisig 2-of-2 compliance gate on every transfer Anchored hashes Documents timestamped, integrity verifiable Settlement Ownership, transfers, distributions — immutable

§8.2 · Off Chain Services Diagram

The services around the chain

Everything user-facing and jurisdiction-specific runs off-chain and touches Mintlayer only at defined points: allocation, co-signing, anchoring.

Whitelabel portal Investor, admin, compliance, finance KYC / AML providers Identity, screening, Chainalysis Payments & documents Rails, reconciliation, versioned storage Integration layer Allocation, co-signing, hash anchoring Mintlayer On-chain truth Jurisdiction-specific logic stays off-chain, so the same on-chain primitives serve every market

§8.4 · Audit and Monitoring Overview

The audit trail, as shipped

The working screen closes this placeholder: every significant event, time-stamped and attributable, with on-chain references where the action settled on Mintlayer.

Audit trail of platform actions compliance-audit-trailOpen the live screen →