Whitepaper figures
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
§2.4 · Fungible Token Model Diagram
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
§2.4 · Non-Fungible Token Unit-Level Diagram
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
§2.4 · Compliance Integration Flow
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.
§2.4 · FT vs NFT Decision Flow
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.
Chapter 3 · Lifecycle of a tokenized asset
§3.1 · Smart Contract Deployment Flow
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.
§3.2.2 · Bitcoin Payment and On-Chain Compliance Flow
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.
§3.2.2 · Multi-Method Payment Overview
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.
§3.2.4 · KYC-to-KYC Transfer Flow
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
§3.2.4 · Transfer Restriction Diagram
Before the compliance key even sees a request, the engine evaluates the restrictions defined at issuance. Any single failure blocks the transfer outright.
§3.3.1 · Reporting Dashboard
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
§3.3.2 · Yield Calculation and Distribution Flow
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.
§3.3.2 · Investor Yield History Panel
Every payout lands in the investor's history with the period covered and the calculation basis — the transparency half of the flow above.
§3.3.3 · Redemption or Buyback Workflow
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.
Chapters 4–5 · Compliance & security framework
§4.1 · KYC and AML Compliance Flow
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.
§4.2 · Legal Intervention and Freeze Logic
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.
§4.4 · Wallet Architecture Overview
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.
§4.5 · Role Based Access Diagram
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
§4.5 · Security and Auditability Overview
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.
Chapter 6 · Platform features
§6.2 · Token Structure and Supply Configuration
§6.2 · Compliance, Vesting, and Redemption Configuration Flow
§6.4 · Notification Flow Diagram
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.
Chapter 7 · Use cases
§7.3 · Tokenized Fund Structure Diagram
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
Chapter 8 · Technical architecture
§8.1 · On Chain Components Diagram
§8.2 · Off Chain Services Diagram
Everything user-facing and jurisdiction-specific runs off-chain and touches Mintlayer only at defined points: allocation, co-signing, anchoring.