RMINT White Paper

Version 6.0 | February 2026

Invest, Earn, Leverage, Grow with RMINT: The AI-Driven DeFi Protocol

RWA tokenization for restaurants — AI-managed operations, on-chain leverage, verifiable yield.

Legal Disclaimer

This white paper is provided for informational purposes only and does not constitute an offer to sell, a solicitation of an offer to buy, or a recommendation of any security, token, or other financial instrument. The tokens described herein (ROTs, RDTs, and RMUSD) are anticipated to be classified as securities under applicable US federal securities laws and will be offered only pursuant to valid exemptions from registration, including but not limited to Regulation D Rule 506(c). Participation in any token offering is restricted to accredited investors as defined by the US Securities and Exchange Commission (SEC) and is subject to applicable Know Your Customer (KYC), Anti-Money Laundering (AML), and accredited investor verification requirements.

Nothing in this document constitutes legal, financial, tax, or investment advice. Prospective investors should consult their own legal, financial, and tax advisors before making any investment decisions. Investing in early-stage tokenized assets involves significant risks, including the potential loss of the entire investment. Past performance is not indicative of future results.

The information contained herein is subject to change without notice. RMINT Inc makes no representations or warranties regarding the accuracy, completeness, or timeliness of the information presented. Forward-looking statements are based on current expectations and assumptions and are subject to risks and uncertainties that could cause actual results to differ materially.

Table of Contents

• Part I: Problem and Vision
  • Section 1: Market Opportunity
  • Section 2: The Problem -- Barriers to Entry and Inefficiencies in Restaurant Investment
  • Section 3: Our Solution -- The RMINT Ecosystem
• Part II: Intellectual Property and Novel Primitives
  • Section 4: Intellectual Property
• Part III: Protocol Architecture
  • Section 5: System Architecture
  • Section 6: Agent Coordination Framework
  • Section 7: Token Standards and On-Chain Compliance
  • Section 8: Smart Contract Specification
• Part IV: Tokenomics
  • Section 9: Restaurant Ownership Tokens (ROTs)
  • Section 10: Restaurant Debt Tokens (RDTs)
  • Section 11: RMUSD Stablecoin (incl. 11.7 Expansion Fund, 11.8 GENIUS Act)
  • Section 12: Fee Structure
• Part V: AI and Risk-Aware Agents
  • Section 13: RAA Architecture
  • Section 14: Protocol-RAA Interaction Loop
  • Section 15: Operational Underwriting Model
• Part VI: Legal and Compliance
  • Section 16: Legal Structure
  • Section 17: SEC Compliance Pathway
  • Section 18: Data Privacy and Security
• Part VII: Governance
  • Section 19: Governance Model
• Part VIII: Competitive Landscape
  • Section 20: Market Positioning
• Part IX: Team, Roadmap, and Risks
  • Section 21: Team and Leadership
  • Section 22: Roadmap
  • Section 23: Risk Factors
• Back Matter
  • Glossary
  • References
  • Appendix A: Patent Summary
  • Appendix B: Smart Contract Interfaces

Executive Summary

Traditional restaurant investment suffers from two systemic failures: illiquidity and operational opacity. Investors commit capital that becomes trapped for years with no secondary exit, while day-to-day restaurant performance remains a black box disconnected from financial outcomes. The result is approximately $900 billion in US restaurant industry assets that are largely inaccessible to mainstream investors and inefficiently managed from a capital markets perspective.

RMINT is an AI-driven DeFi protocol that transforms this paradigm. Rather than simply tokenizing restaurant equity -- a necessary but insufficient step -- RMINT establishes a system where autonomous Risk-Aware Agents (RAAs) execute restaurant operations under protocol-managed, on-chain incentive structures. Operational performance is recorded as verifiable blockchain metrics, creating a transparent and continuous link between how a restaurant operates and what its tokens are worth. This verifiable operational management constitutes operational underwriting -- the protocol's ability to provide quantifiable confidence in the predictability and quality of the cash flows backing each tokenized asset.

The AI Engine aggregates consumer preferences and demand signals -- captured through the consumer-facing app -- to generate demand-informed menu recommendations for each restaurant. Restaurants receive daily guidance on what to cook, when, and at what price, closing the loop between what customers want and what gets produced.

The core protocol architecture comprises six interconnected smart contract modules deployed on Base L2: a Tokenization Module issuing ERC-3643 compliant security tokens, a Custody Management Module, a Settlement Module distributing revenue, a Stablecoin Issuance Module (RMUSD), an Agent Coordination Module managing RAA lifecycle and performance metrics, and an AI Interface Module receiving strategic recommendations from the off-chain AI Engine. This architecture is further supported by on-chain identity verification, jurisdiction-based transfer restrictions, and regulatory lock-up enforcement -- all built to satisfy SEC Reg D 506(c) compliance requirements.

Each tokenized restaurant is structured as an independent Special Purpose Vehicle (SPV), with equity distributed across four stakeholder classes: 30% to investors via public token sales, 30% to chef-operators via vesting contracts, 30% to the RMINT AI Engine for operational management, and 10% to a performance and strategic pool. Revenue flows through a priority waterfall enforced by smart contracts, with an automated "kill switch" that redirects gross revenue to protect debt and stablecoin obligations in the event of a solvency breach.

The RMINT ecosystem enables participants to:

• Invest: Access fractional restaurant ownership (ROTs) or debt instruments (RDTs) through compliant, on-chain token sales with as little as a few thousand dollars.
• Earn: Receive yield from restaurant operations distributed as USDC dividends, with performance driven by AI-optimized, protocol-managed autonomous agents.
• Leverage: Unlock previously illiquid capital by collateralizing ROTs to mint the RMUSD stablecoin, backed by operationally underwritten cash flows.
• Grow: Benefit from capital appreciation as RAA-driven operational improvements, portfolio expansion, and ecosystem adoption increase token value.

This white paper details the technical architecture, tokenomics, AI agent framework, legal structure, governance model, competitive positioning, team credentials, development roadmap, and risk factors of the RMINT ecosystem.

Section 1: Market Opportunity

1.1 The Restaurant Industry

The United States restaurant industry generates approximately $900 billion in annual revenue, employs over 15 million people, and comprises more than one million restaurant locations. It is one of the largest sectors of the US economy, yet it remains one of the least efficient from an investment and capital markets perspective.

Private restaurant ownership is characterized by:

• High capital requirements: Opening a single full-service restaurant requires $275,000 to $750,000 or more in initial capital, depending on location, concept, and build-out costs.
• Long payback periods: The average restaurant takes 2-5 years to achieve full return on invested capital, with a significant number failing to reach profitability.
• Illiquid positions: Once capital is deployed, investors face multi-year lock-ups with no standardized mechanism for secondary sale or capital recovery.
• Opaque operations: Most restaurant investors receive quarterly or annual financial reports at best, with limited insight into the daily operational decisions that determine financial performance.

Despite these challenges, the restaurant sector offers compelling returns for well-managed operations. The average profit margin for a full-service restaurant ranges from 3-9%, but top-quartile operators consistently achieve margins of 15-25% through operational discipline, data-driven menu engineering, and efficient labor management. The gap between median and top-quartile performance represents the opportunity that AI-driven operational management can capture.

1.2 The Tokenization Market

The global market for tokenized real-world assets (RWAs) exceeded $36 billion by late 2025 (excluding stablecoins), according to the Canton Network State of RWA Tokenization 2026 report. Crypto.com Research (March 2025) projects the tokenized RWA market to reach $16 trillion by 2030, representing approximately 10% of global GDP, as institutional adoption accelerates.

Key drivers of RWA tokenization growth include:

• Regulatory clarity: The SEC's January 2026 statement confirmed that tokenization is a change in technology only -- tokenized securities remain fully subject to existing federal securities laws, providing a clear compliance framework.
• Institutional adoption: BlackRock's BUIDL fund ($1.7B+ AUM), Franklin Templeton's on-chain money market fund, and Ondo Finance's USDY have demonstrated institutional demand for tokenized assets.
• Infrastructure maturity: Layer 2 networks (Base, Arbitrum, Optimism) provide sub-cent transaction costs with Ethereum-grade security, making retail-sized transactions economically viable.
• Standards convergence: ERC-3643 (T-REX) has emerged as the industry standard for regulated security tokens, with over $28 billion in assets tokenized using this standard.

However, existing RWA tokenization efforts have concentrated on financial assets (treasuries, credit, real estate) with relatively simple operational profiles. Tokenized restaurant equity represents a new frontier -- one where the operational complexity of the underlying business creates both the challenge and the opportunity for differentiated value creation through AI-managed operations.

1.3 The Convergence Opportunity

RMINT sits at the intersection of three converging trends:

1. Restaurant industry inefficiency ($900B market with systemic capital lock-up and opacity)
2. RWA tokenization infrastructure maturity ($36B+ market with clear regulatory pathways)
3. AI agent capabilities (autonomous AI agents managing wallets, executing transactions, and making operational decisions on-chain)

This convergence creates a unique opportunity: apply autonomous AI agents not merely as analytics tools, but as protocol-managed operational partners whose performance is verifiable, incentivized, and recorded immutably on-chain. The result is a new class of tokenized asset where operational quality is not assumed or reported -- it is underwritten by the protocol itself.

Section 2: The Problem -- Barriers to Entry and Inefficiencies in Restaurant Investment

2.1 High Barriers to Entry

Investing in restaurant businesses has historically been reserved for wealthy individuals with industry connections. The minimum investment for a single restaurant typically ranges from $100,000 to $500,000 for an equity stake, with limited-partnership structures requiring even larger commitments. Franchised concepts demand minimum net worth requirements of $500,000 to $5,000,000 depending on the brand. This excludes the vast majority of potential investors who may seek exposure to the restaurant sector's returns.

2.2 Severe Illiquidity and Capital Inefficiency

Once capital is deployed into a restaurant venture, it becomes effectively trapped. There is no standardized secondary market for restaurant equity. Selling a stake in a private restaurant requires finding a willing buyer, negotiating terms bilaterally, and navigating complex legal agreements -- a process that can take months to years or may be impossible entirely.

This illiquidity creates dead capital: invested funds that cannot be redeployed, leveraged, or recovered in response to changing market conditions, personal financial needs, or better investment opportunities elsewhere. The inability to unlock this capital represents a significant drag on investor returns and limits the total addressable capital available to the restaurant industry.

2.3 Operational Complexity and Human Capital Dependence

Restaurant operations are among the most management-intensive of any business. Daily operations require coordinating procurement, inventory management, labor scheduling, menu pricing, quality control, and customer experience -- all in a perishable-goods environment with thin margins. Success depends heavily on the performance of key personnel, particularly the head chef and general manager. Staff turnover in the restaurant industry averages 75% annually, creating persistent operational risk.

Human inconsistency in executing these daily tasks translates directly into financial volatility. A single week of poor labor scheduling or inventory mismanagement can eliminate a month's profit margin. Yet traditional investment structures provide no mechanism to systematically monitor, measure, or optimize these operational variables in real time.

2.4 Lack of Transparency for Passive Investors

Passive restaurant investors typically receive financial reports on a quarterly or annual basis -- if at all. These reports reflect past performance and provide no insight into the daily operational decisions that drive financial outcomes. Investors cannot see whether food costs are trending above target, whether labor hours are being optimized, or whether menu pricing is responding to ingredient cost changes. This opacity makes it impossible for investors to assess risk accurately or to differentiate between well-managed and poorly-managed operations.

2.5 Absence of Verifiable Operational-Financial Linkage

Perhaps the most fundamental problem is the absence of a reliable, verifiable mechanism to connect operational decisions to financial outcomes. In traditional restaurant investment, it is exceedingly difficult to determine:

• How a specific operational decision (e.g., changing a supplier, adjusting a menu price) impacted revenue or cost metrics
• Whether operational targets (food cost percentage, labor cost percentage, prime cost ratio) are being met on a daily or weekly basis
• Whether the operational performance of a restaurant justifies the valuation placed on its equity

Without this linkage, underwriting restaurant investments relies on historical financials and subjective assessments of management capability -- a fundamentally inadequate approach for asset-backed financial instruments.

2.6 Conclusion

Collectively, these problems make traditional restaurant investment inaccessible, risky, illiquid, operationally complex, opaque, and lacking the verifiable operational-financial linkage required for robust financial engineering. There is a clear need for a solution that democratizes access, provides verifiable operational and financial transparency, enhances liquidity through trustworthy leverage mechanisms, and optimizes operations through accountable autonomous agents whose performance is recorded on-chain.

Section 3: Our Solution -- The RMINT Ecosystem

To overcome these barriers, the RMINT ecosystem integrates blockchain tokenization, AI-driven autonomous agents, on-chain compliance infrastructure, and a novel operational underwriting framework. We transform illiquid private restaurant investments into dynamic, digitally represented assets offering yield, growth potential, and liquidity through leverage -- all founded on verifiable, protocol-managed operational performance.

3.0 End-to-End Tokenization: Three Verticals

RMINT is an end-to-end tokenization platform for restaurants. When an investor purchases ROTs or RDTs, the protocol tokenizes three distinct elements:

RMINT provides all three verticals integrated in a single system. Section 8 maps each smart contract to its primary tokenization vertical.

                RMINT End-to-End Tokenization

+-------------------------------------------------------------------+
|  VERTICAL 1: Tokenizing Private Credit                            |
|  Investor USDC -> TokenSale -> ROTs/RDTs (ERC-3643)               |
|  Contracts: TokenFactory, RMOTToken, TokenSale,                   |
|             ChefVesting, Compliance                               |
+-------------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------------+
|  VERTICAL 2: Tokenizing Restaurant Operations                     |
|  RAAs execute ops -> Metrics on-chain -> Operational underwriting  |
|  Contracts: AgentCoordination, AIDataOracle,                      |
|             PriceOracle, Protocol-POS                             |
+-------------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------------+
|  VERTICAL 3: Tokenizing Cashflow                                  |
|  Revenue -> RevenueDistributor -> USDC to holders                 |
|  ROTs -> CollateralVault -> RMUSD (Reserve Proofs attest value)   |
|  Contracts: RevenueDistributor, CollateralVault,                  |
|             RMUSD, Reserve Proofs                                 |
+-------------------------------------------------------------------+

3.1 Tokenized Fractional Ownership (ROTs)

RMINT enables investment via Restaurant Ownership Tokens (ROTs) representing fractional economic rights in SPV-held restaurant assets. ROTs are issued as ERC-3643 (T-REX) compliant security tokens on Base L2, with built-in identity verification, jurisdiction-based transfer restrictions, and regulatory lock-up enforcement. Each restaurant's token supply is fixed at issuance and distributed according to a defined allocation:

• 30% Investor Allocation: Sold to accredited investors via compliant token sales (Reg D 506(c)).
• 30% Chef/Co-Owner Allocation: Vested over 36 months with a 6-month cliff, subject to break-even triggers.
• 30% AI Engine Allocation: Held by RMINT Technology LLC for operational management, with portions subject to performance-based vesting against measurable KPIs.
• 10% Performance and Strategic Pool: Reserved for performance incentives, strategic partnerships (e.g., real estate partners), and future allocations.

ROT value reflects the underlying restaurant's performance as actively measured and enhanced by the protocol's AI and Risk-Aware Agent (RAA) management systems.

3.2 Tokenized Debt Financing (RDTs)

RMINT facilitates the issuance of Restaurant Debt Tokens (RDTs) representing loans to specific restaurant SPVs. RDTs offer investors compliant fixed-income opportunities with defined coupon rates, maturity dates, and typically senior claim status relative to equity. RDTs are issued as ERC-3643 compliant tokens with the same identity and transfer restriction infrastructure as ROTs.

3.3 Risk-Aware Agent (RAA) Driven Operations

The core innovation of the RMINT ecosystem is the protocol's coordination of autonomous Risk-Aware Agents (RAAs) for restaurant operations. RAAs are sophisticated AI entities that:

• Aggregate consumer preferences and demand signals from the consumer app to generate demand-informed daily menu recommendations -- so each restaurant knows what to cook based on what customers want
• Translate consumer demand into actionable operational workflows: menu directive, schedule, and pricing for each restaurant
• Execute day-to-day restaurant operations (procurement optimization, menu pricing, labor scheduling, inventory management) autonomously
• Translate operational actions into verifiable on-chain performance metrics (food cost %, labor cost %, prime cost ratio, revenue proxies, working capital indicators)
• Operate under protocol-managed, on-chain incentive structures that link operational performance to stablecoin rewards and penalties
• Report performance through cryptographically signed attestations validated by the protocol's Agent Coordination Contract

This system moves restaurant management from human-dependent, opaque execution to protocol-managed, verifiable, incentive-aligned autonomous operation.

3.4 Operational Underwriting and RMUSD Stablecoin Leverage

By managing RAAs through verifiable on-chain metrics and enforceable incentives, the protocol establishes operational underwriting -- a trustworthy framework that provides quantifiable confidence in the predictability and quality of cash flows generated by each tokenized restaurant.

This operational underwriting enhances the quality and reliability of ROTs used as collateral, enabling the RMUSD stablecoin protocol to offer robust leverage. Holders can lock ROTs to mint RMUSD (a USD-pegged stablecoin), confidently unlocking previously dead capital because the underlying operations are transparently managed and underwritten by the protocol.

RMUSD is backed not by static physical assets, but by verified, high-Sharpe operational cash flows, with peg security enforced through:

• Algorithmic Revenue Sweep: The protocol integrates at the payment gateway level, capturing revenue before it reaches the restaurant's operating wallet.
• Priority Waterfall: Smart contracts enforce a strict distribution order -- debt service first, essential operations second, owner profit last.
• Solvency Kill Switch: In the event of a Sharpe Ratio breach, the protocol automatically redirects 100% of gross revenue to the debt vault and stablecoin treasury, creating a digital, unbreakable lien superior to all equity claims.

3.5 Closed-Loop Financial Enclosure

Unlike traditional RWA protocols that rely on external audits of physical cash registers, RMINT enforces a "Protocol-as-POS" architecture:

• Mobile-First Operations: The consumer-facing mobile application serves as the sole Point of Sale (POS), eliminating physical cash handling entirely.
• Crypto-Native Payments: Diners pay with RMUSD or USDC at checkout -- no credit card in the closed-loop. Revenue originates on-chain. This eliminates ~3% card interchange fees; savings can be shared (e.g., 2% diner discount).
• On-Chain Expense Cycle: All operational outflows -- vendor payments, employee salaries, supply purchases -- are executed via stablecoin disbursements managed by the protocol.
• Zero-Leakage Standard: Revenue is not reported to the blockchain; it is originated on-chain. This creates an immutable, digitally enclosed cash flow machine with zero possibility of off-books leakage.

3.5.1 RMINT Wallet (Web)

For App Store and Play Store compliance at first launch, the RMINT wallet lives entirely on the web (wallet.rmint.com). The mobile app provides a link; all crypto operations (balance, pay, top-up) happen on the web. In-app checkout uses card, Apple Pay, or prepaid balance (card-funded). This ensures no crypto code in the app binary while enabling crypto-native payments for users who complete transactions on the web.

3.5.2 Consumer-AI Interaction

Consumers interact with the AI through the mobile app via chat, recommendations, and search. Example flows include "Recommend kid-friendly menus", "Low-calorie options near me", and "Weekend party menus". This demand is aggregated and fed into the AI Engine to drive menu recommendations for each restaurant. The result is a closed loop: consumer preferences inform what gets produced, and restaurants receive daily guidance aligned with what customers want.

3.6 The Integrated Value Proposition

The RMINT ecosystem enables participants to:

• Invest: Access ownership (ROTs) or debt (RDTs) in restaurants with autonomously managed and underwritten operations, starting from investment minimums as low as a few thousand dollars.
• Earn: Receive yield (ROTs) or fixed interest (RDTs) from operations reflected in verifiable on-chain metrics, distributed as USDC.
• Leverage: Unlock significant liquidity from ROTs via the RMUSD stablecoin, founded on protocol-underwritten RAA operations.
• Grow: Benefit from ROT capital appreciation driven by demonstrable RAA performance, operational efficiency gains, and ecosystem expansion.

Section 4: Intellectual Property

4.1 Patent Protection

The core RMINT protocol architecture is protected by United States Patent No. 12,541,765 B2, granted on February 3, 2026, and assigned to Rmint Inc. The patent covers the AI-driven coordination of incentivized Risk-Aware Agents for tokenized asset management.

4.2 Key Innovations (User-Facing Value)

RMINT's innovation rests on six capabilities that deliver distinct value to participants:

• Operational underwriting: Investors receive verifiable confidence in cash flows -- operational performance is measured, validated, and recorded on-chain in real time.
• Agent coordination as on-chain hub: A dedicated smart contract serves as the single source of truth for RAA lifecycle, scope, incentives, performance metrics, and reward/penalty distribution.
• AI-RAA feedback loop: A continuous cycle where AI analysis influences on-chain incentives, RAAs execute operations, validated metrics feed back, and the protocol refines -- creating progressively better outcomes.
• Protocol-native stablecoin: RMUSD settles RAA rewards and penalties and provides leverage against operationally underwritten assets.
• Protocol-delegated custody: RAAs exercise custody control within defined boundaries, gated by lifecycle status and performance metrics.
• Verifiable operational management enabling leverage: Protocol-verified RAA performance establishes the collateral integrity required for stablecoin-based leverage against traditionally opaque and illiquid assets.

Section 5: System Architecture

5.1 Design Principles

The RMINT protocol architecture is governed by five design principles:

1. Modular architecture: The on-chain module structure maps to six interconnected modules (Tokenization, Custody, Settlement, Stablecoin, Agent Coordination, AI Interface), each implementing a distinct protocol capability.
2. QuillAudits RWA compliance: The system satisfies the six critical layers defined by the QuillAudits RWA System Design handbook -- off-chain participants, smart contracts and token standards, off-chain to on-chain data flow, identity and compliance, settlement and accounting, and legal mapping.
3. Regulatory enforceability: On-chain compliance is not optional or advisory. ERC-3643 identity verification, jurisdiction-based transfer restrictions, and regulatory lock-ups are enforced at the smart contract level, making non-compliant transactions technically impossible.
4. Per-restaurant isolation: Each tokenized restaurant operates through its own set of smart contracts linked to an independent SPV. A failure in one restaurant's operations cannot propagate to another restaurant's token holders.
5. Phased deployment: The architecture supports incremental activation. Phase 1-2 operates with USDC settlement and core tokenization. Phase 3 adds the RMUSD stablecoin and DeFi layer. Phase 4+ activates the full Agent Coordination and AI Interface modules.

5.2 Target Blockchain: Base L2

All RMINT smart contracts deploy on Base, the Ethereum Layer 2 network incubated by Coinbase:

• Chain ID: 84532 (Base Sepolia testnet, Phases 1-3) / 8453 (Base Mainnet, Phase 4+)
• Transaction costs: Sub-cent per transaction ($0.001-$0.01), making retail-sized investment transactions economically viable
• Security model: Inherits Ethereum L1 security via optimistic rollup architecture
• Settlement finality: Transactions settle to Ethereum L1 within minutes
• Ecosystem advantages: Native Coinbase on/off-ramp integration, growing RWA ecosystem, full EVM compatibility. Base is the commerce L2 -- Stripe, Shopify, and JPMorgan's JPMD use it for payments.
• RPC infrastructure: Alchemy-powered endpoints (https://base-sepolia.g.alchemy.com/v2/{API_KEY})

The choice of Base over alternatives (zkSync, Polygon, Arbitrum) reflects the platform's focus on regulatory-friendly infrastructure and fiat on-ramp accessibility through the Coinbase ecosystem.

5.3 Six-Module On-Chain Architecture

The on-chain system comprises six interconnected smart contract modules:

┌─────────────────────────────────────────────────────────────────────────┐
│                         BASE L2 (BLOCKCHAIN)                            │
│                                                                         │
│  ┌──────────────┐  ┌──────────────┐  ┌─────────────────────────────┐   │
│  │ Tokenization │  │   Custody    │  │      Settlement             │   │
│  │ Module       │  │ Module       │  │      Module                 │   │
│  │              │  │              │  │                             │   │
│  │ TokenFactory │  │ Gnosis Safe  │  │ RevenueDistributor          │   │
│  │ RMOTToken    │  │ Collateral   │  │ TokenSale                   │   │
│  │ (ERC-3643)   │  │ Vault        │  │ InterestDistributor         │   │
│  └──────┬───────┘  └──────┬───────┘  └──────────────┬──────────────┘   │
│         │                 │                          │                  │
│  ┌──────┴─────────────────┴──────────────────────────┴──────────────┐   │
│  │                    Compliance Layer                               │   │
│  │  IdentityRegistry ◄─► ComplianceModule ◄─► ClaimTopicsRegistry   │   │
│  │                         TrustedIssuersRegistry                    │   │
│  └──────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│  ┌──────────────┐  ┌──────────────────┐  ┌──────────────────────┐      │
│  │  Stablecoin  │  │ Agent Coord.     │  │  AI Interface        │      │
│  │ Module       │  │ Module           │  │  Module               │      │
│  │              │  │                  │  │                      │      │
│  │ RMUSD        │  │ AgentCoord.      │  │ AIDataOracle         │      │
│  │ Stability    │  │ RAA Lifecycle    │  │ PriceOracle          │      │
│  │ Liquidation  │  │ Metrics/Rewards  │  │ Reserve Proofs       │      │
│  └──────────────┘  └──────────────────┘  └──────────────────────┘      │
│                                                                         │
│  Phase 1-2: ████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░     │
│  Phase 3:   ████████████████████████████████████████░░░░░░░░░░░░░░     │
│  Phase 4+:  ████████████████████████████████████████████████████████    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

5.4 Off-Chain Components

Three off-chain components complete the system:

Protocol Management Processor -- Built on Next.js with server-side API routes, the Processor orchestrates communication between the AI Engine, RAAs, and on-chain contracts. It manages user authentication via Alchemy Account Kit (ERC-4337 smart accounts), validates RAA reports before on-chain submission, aggregates on-chain data for AI analysis, and serves the investor/admin/chef dashboard interfaces.

AI Engine -- The off-chain analytical system that ingests restaurant operational data (POS transactions, inventory levels, labor schedules, customer metrics), performs risk/return analysis, generates operational recommendations, and proposes adjustments to RAA incentive parameters and performance targets. The AI Engine's recommendations flow through the Processor to the Agent Coordination and AI Interface modules on-chain.

Risk-Aware Agents (RAAs) -- Autonomous software agents, each with its own cryptographic identity provisioned via Alchemy's AlchemyServerSigner (server-side signing with no user interaction required). RAAs interact with on-chain contracts through scoped Session Keys that enforce spending limits, contract-specific access, and time-based restrictions -- enabling autonomous operational transactions within protocol-defined boundaries.

5.5 End-to-End Workflow

The protocol operates through the following lifecycle:

1. Restaurant Onboarding: Admin creates SPV, deploys restaurant-specific contracts via TokenFactory, mints ROT supply to Gnosis Safe Treasury.
2. Token Distribution: Treasury allocates 30% to investor TokenSale, 30% to ChefVesting, 30% to AI Engine wallet, 10% to Performance Pool.
3. Investor Acquisition: Accredited investors complete KYC, receive on-chain identity attestation in IdentityRegistry, purchase ROTs with USDC via TokenSale.
4. Demand Aggregation: Consumers express preferences via the app (chat, recommendations, search); AI aggregates demand signals and predicts volume.
5. Menu Directive Generation: AI generates daily menu recommendations, schedules, and pricing for each restaurant.
6. Operational Loop: RAAs execute operations guided by the demand-informed directive, report performance metrics, receive rewards/penalties via AgentCoordination.
7. Revenue Distribution: Restaurant revenue flows through smart contracts: RevenueDistributor calculates pro-rata entitlements, investors claim USDC dividends.
8. Leverage (Phase 3+): ROT holders lock tokens in CollateralVault to mint RMUSD, unlocking liquidity from operationally underwritten assets.

Section 6: Agent Coordination Framework

6.1 Overview

The Agent Coordination Module is the central hub that manages the relationship between the RMINT protocol and its Risk-Aware Agents. This module transforms the protocol from a passive tokenization platform into an active operational management system.

6.2 Investor Levers and On-Chain State Sync

Investors have levers to control and guide the AI Engine. Financial transactions and market data flow on-chain, giving ROT holders visibility into restaurant operations and the ability—through governance—to influence profitability metrics and incentive parameters. Restaurant state, financial metrics, and RAA performance are continuously synced on-chain, creating a transparent feedback loop between capital and operations.

How investors guide the AI:

The dual-engine architecture (CRO and CFO) executes under these parameters: the CRO Engine optimizes revenue and menu performance; the CFO Engine enforces cost discipline. Both respond to the incentive rules and targets that governance sets. In later phases, ROT holders participate in on-chain votes to adjust these parameters, aligning the AI Engine with investor objectives.

Accountability when performance lags: When metrics breach thresholds, the protocol responds automatically—penalties apply, corrective measures escalate, and transitions are recorded on-chain. This accountability layer operates passively in the background, reinforcing that the AI Engine is directed by investor-defined parameters rather than opaque management.

6.3 On-Chain Performance Metrics

The Agent Coordination Contract maintains structured performance data for each active RAA:

These metrics serve three functions: (1) they are inputs to the AI Engine's analysis, (2) they determine RAA reward/penalty calculations, and (3) they feed the Price Oracle for ROT valuation.

6.4 Incentive Rules and Settlement

The protocol defines configurable incentive rules that link operational metrics to stablecoin-denominated rewards and penalties:

IncentiveRule {
    metricId:       bytes32     // Which metric (e.g., keccak256("foodCostPct"))
    targetValue:    uint256     // Target threshold (e.g., 3000 = 30.00%)
    rewardAmount:   uint256     // USDC reward for meeting/beating target
    penaltyAmount:  uint256     // USDC penalty for missing target
    direction:      enum        // BELOW_TARGET (cost metrics) or ABOVE_TARGET (revenue)
    isActive:       bool        // Can be toggled by governance
}

When an RAA submits a performance report:

1. The Agent Coordination Contract verifies the RAA's ECDSA signature
2. Validates the RAA's current lifecycle status is Active
3. Compares each reported metric against its corresponding incentive rule
4. Calculates the net reward or penalty
5. Transfers the settlement amount in USDC (Phase 1-2) or RMUSD (Phase 3+)
6. Updates the RAA's on-chain performance metrics
7. Emits events for indexing and audit trail

6.5 Alchemy AI Agent Infrastructure

RAA wallet infrastructure is built on Alchemy's AI Agent platform, leveraging:

• AlchemyServerSigner: Each RAA receives a dedicated server-side signer (signerType: "alchemy-server-signer") that can sign messages and typed data using access keys with no user interaction. This provides the cryptographic identity required for autonomous RAA operations.
• Session Keys: RAAs operate through scoped session keys with granular permissions:
  • erc20-token-transfer: Spending limits on USDC/RMUSD for operational transactions
  • functions-on-contract: Restrict RAA to specific functions on AgentCoordination.sol (e.g., submitReport, claimReward)
  • gas-limit: Budget for gas consumption per session
  • Time-based expiry: Sessions auto-expire unless renewed based on Active lifecycle status
• Smart Accounts (ERC-4337): Each RAA operates through an ERC-4337 smart contract account with gasless transaction capabilities via Alchemy's gas sponsorship policies.

This architecture is validated by Virtuals Protocol's deployment of 17,000+ AI agents with $8B+ in locked value using the same Alchemy smart wallet infrastructure.

Section 7: Token Standards and On-Chain Compliance

7.1 ERC-3643 (T-REX) Standard

All RMINT security tokens (ROTs and RDTs) are issued as ERC-3643 compliant tokens -- the Token for Regulated EXchanges (T-REX) standard. ERC-3643 is the industry standard for on-chain securities, with over $28 billion in assets tokenized using this framework. The standard was specifically designed for regulated security tokens and provides:

In TradFi, CUSIPs (9-character security identifiers) standardize settlement and clearing across brokers and custodians. For on-chain securities, ERC-3643 and the token contract address serve an analogous role:

Any ERC-3643-compliant wallet, ATS, or DeFi protocol can identify, verify identity, and enforce transfer rules for RMINT tokens using the contract address and standard interface.

• Built-in Identity Registry: Every token holder must be registered in an on-chain IdentityRegistry before they can receive or transfer tokens. This enforces KYC/AML at the protocol level, not just at the application level.
• Transfer Hooks: The _beforeTokenTransfer hook queries the ComplianceModule before every transfer, enabling automatic enforcement of jurisdiction restrictions, lock-up periods, and holder count limits.
• Claim-Based Identity: The ClaimTopicsRegistry defines what identity claims are required (e.g., KYC verification, accredited investor status, jurisdiction), while the TrustedIssuersRegistry defines which entities are authorized to issue those claims.
• Regulatory Controls: Built-in capabilities for pause() (halt all transfers), freeze(address) (freeze specific accounts for AML), and forceTransfer() (court-ordered recovery) -- all required by securities regulators.

7.2 On-Chain Identity Verification

The compliance infrastructure comprises four interlinked contracts:

IdentityRegistry.sol: Maps wallet addresses to verified identity claims.

registerIdentity(walletAddress, countryCode, kycClaimHash)
    -> User's wallet is whitelisted for token transfers
    -> All subsequent transfers automatically verify identity status

ClaimTopicsRegistry.sol: Defines required claim types:

• Claim Topic 1: KYC Verification (required for all participants)
• Claim Topic 2: Accredited Investor Status (required for Reg D 506(c))
• Claim Topic 3: Jurisdiction (for country-based transfer restrictions)

TrustedIssuersRegistry.sol: Authorizes identity claim issuers (e.g., Sumsub for KYC, Parallel Markets for accredited investor verification).

ComplianceModule.sol: Enforces transfer rules:

• Jurisdiction-based restrictions (blocked countries list)
• Maximum holder count per jurisdiction (regulatory limits)
• Per-address lock-up period enforcement (12-month Reg D holding period)
• Daily transfer volume limits (circuit breaker)

7.3 Per-Address Regulatory Lock-Up

SEC Regulation D Rule 506(c) requires a 12-month holding period from the date of purchase by each investor -- not from the date of token issuance. The RMOT contract implements per-address lock-up tracking:

mapping(address => uint256) public lockupExpiry;

// Set when tokens are transferred to investor via TokenSale
// lockupExpiry[investor] = block.timestamp + 365 days;

function _beforeTokenTransfer(address from, address to, uint256 amount) internal {
    require(block.timestamp >= lockupExpiry[from], "Regulatory lock-up active");
    require(identityRegistry.isVerified(to), "Recipient not KYC verified");
    require(complianceModule.canTransfer(from, to, amount), "Transfer not compliant");
}

Chef vesting tokens follow the same principle: the lock-up starts from each vesting claim date, not from the initial token mint.

7.4 Emergency Provisions

All RMOT contracts include emergency controls required by securities regulators and recommended by QuillAudits:

• emergencyPause() -- callable by REGULATOR_ROLE, halts all transfers globally
• forceFreeze(address account, uint256 amount) -- callable by COMPLIANCE_ROLE, freezes specific accounts (AML requirement)
• forceTransfer(address from, address to, uint256 amount) -- callable by COMPLIANCE_ROLE, enables legal recovery (court orders)
• migrateCustodian(address newCustodian) -- callable by DEFAULT_ADMIN_ROLE, handles custodian failure scenarios

All emergency actions emit events for a complete audit trail.

Section 8: Smart Contract Specification

8.1 Contract Suite Overview

Each tokenized restaurant deploys the following contract set via the TokenFactory:

8.1.1 Contract Mapping to Tokenization Verticals

Each contract supports one or more of the three tokenization verticals (Section 3.0):

EIP-712 Reserve Proofs (Section 15.5) support cashflow tokenization by attesting the value backing tokens. They are planned for Phase 2/3 and are not yet implemented in contracts.

Upgradeability rationale: Token contracts (RMOTToken, TokenSale, ChefVesting) are immutable because investors need assurance that token logic and sale terms will not change after deployment. Infrastructure contracts (IdentityRegistry, ComplianceModule, RevenueDistributor) are upgradeable because compliance rules evolve and distribution logic may be refined. DeFi contracts (RMUSD, CollateralVault) use UUPS proxy with a 48-72 hour timelock to provide governance oversight on upgrades.

8.2 TokenFactory.sol

The deployment orchestrator that creates the full contract suite for each restaurant:

deployRestaurantToken(
    name:       string,      // "Bistro Nouveau ROT"
    symbol:     string,      // "ROT-BNM"
    totalSupply: uint256,    // Fixed supply, 18 decimals
    spvAddress: address,     // SPV LLC on-chain address
    psaHash:    bytes32      // IPFS hash of Private Placement Memorandum
) -> (rmotAddress, tokenSaleAddress, vestingAddress, safeAddress)

After deployment:

1. Total supply is minted to the restaurant's Gnosis Safe Treasury
2. MINTER_ROLE is renounced on the RMOT contract (supply becomes permanently fixed)
3. Deployment details are stored in deployments/{chainId}.json and verified on Basescan
4. All contract addresses are registered in the central AddressRegistry.sol

8.3 RMOTToken.sol

The per-restaurant equity token implementing the full ERC-3643 (T-REX) interface:

// Immutable references to legal entity and documents
address public immutable spvEntity;               // SPV LLC address
string  public constant PSA_HASH = "ipfs://...";  // Private Placement Memorandum
string  public constant OA_HASH  = "ipfs://...";  // Operating Agreement

// Linked compliance infrastructure
IdentityRegistry  public identityRegistry;
ComplianceModule  public complianceModule;

// Per-address regulatory lock-up (Reg D 12-month)
mapping(address => uint256) public lockupExpiry;

// Emergency controls
function emergencyPause() external onlyRole(REGULATOR_ROLE);
function forceFreeze(address account, uint256 amount) external onlyRole(COMPLIANCE_ROLE);
function forceTransfer(address from, address to, uint256 amount) external onlyRole(COMPLIANCE_ROLE);

Decimal precision: 18 decimals (standard ERC-20). All internal calculations use 18-decimal precision. USDC (6 decimals) is normalized at the interface boundary: normalizedAmount = usdcAmount * 1e12.

8.4 TokenSale.sol

Manages compliant investor acquisition of ROTs:

• Accepts USDC payments (approve + transferFrom)
• Verifies buyer is whitelisted in IdentityRegistry (KYC + accredited investor)
• Enforces minimum/maximum investment per investor
• Time-bounded sale phases (configurable start/end)
• Hardcap on total raise per restaurant
• Sets 12-month lock-up on purchased tokens (lockupExpiry[buyer] = block.timestamp + 365 days)
• Refund mechanism if softcap is not met within the sale period
• Inherits ReentrancyGuard for protection against reentrancy attacks

8.5 ChefVesting.sol

Manages vesting of the chef/co-owner 30% equity allocation:

• Cliff period: 6 months (no tokens released before cliff)
• Linear vesting: Remaining tokens vest linearly over 30 months (36 months total)
• Break-even trigger: Vesting clock may start from restaurant break-even date rather than deployment date, determined by oracle confirmation
• claimVestedTokens() -- releases unlocked tokens to chef's wallet
• vestedAmount(address) view returns (uint256) -- current vested balance
• Revocation by admin (ADMIN_ROLE) for departure scenarios, with unvested tokens returning to Treasury Safe
• Each claimed token batch receives its own 12-month lock-up from claim date

8.6 RevenueDistributor.sol

Distributes restaurant revenue to token holders via epoch-based claims:

• depositRevenue(uint256 amount) -- admin deposits USDC revenue, creating a new distribution epoch
• Pro-rata calculation based on token holdings at epoch snapshot:
  • 30% to investor ROT holders (proportional to individual holdings within the 30% investor supply)
  • 30% to chef via vesting contract or direct
  • 30% to AI Engine wallet
  • 10% to performance/strategic pool
• claimDividend(uint256 epochId) -- token holders claim their share for a specific epoch
• Unclaimed dividends remain available indefinitely (no expiration)
• Inherits ReentrancyGuard

8.7 Circuit Breakers

All financial contracts implement circuit breakers as recommended by QuillAudits:

uint256 public constant MAX_DAILY_MINT       = 1_000_000e18;  // Max RMUSD minted per day
uint256 public constant MAX_SINGLE_TRANSFER  = 500_000e18;    // Max single ROT transfer
uint256 public constant ORACLE_STALENESS     = 86400;         // 24-hour oracle freshness requirement

8.8 Development Framework

All smart contracts are developed using Foundry:

• Solidity compilation and testing via forge
• Native Solidity unit tests (no JavaScript test wrappers)
• Built-in fuzzing for edge case discovery
• Gas profiling for optimization
• Deployment scripts via script/Deploy.s.sol with deterministic deployment (CREATE2)
• Post-deployment verification on Basescan via forge verify-contract
• All deployment addresses stored in deployments/{chainId}.json

Security measures include OpenZeppelin's ReentrancyGuard on all financial contracts, AccessControlEnumerable for role management, and TimelockController (48-72 hour delay) for all upgradeable contract governance.

Section 9: Restaurant Ownership Tokens (ROTs)

9.1 Token Characteristics

9.2 Allocation Structure

Each restaurant's total ROT supply is allocated according to a fixed structure defined at issuance:

Total ROT Supply (100%)
│
├── 30%  Investor Allocation
│         Sold via TokenSale contract to accredited investors.
│         Subject to 12-month per-address lock-up (Reg D).
│         Entitles holders to pro-rata revenue distributions.
│         Serves as collateral for RMUSD minting (Phase 3+).
│
├── 30%  Chef / Co-Owner Allocation
│         Held in ChefVesting contract.
│         6-month cliff, 30-month linear vesting (36 months total).
│         Vesting may be triggered by break-even milestone.
│         Revocable by admin upon departure (unvested returns to Treasury).
│         Each claimed batch subject to 12-month lock-up from claim date.
│
├── 30%  AI Engine Allocation
│         Transferred to RMINT Technology LLC wallet.
│         Portion subject to performance-based vesting against KPIs:
│           - Target profit margin improvement
│           - Demonstrable risk reduction in debt servicing
│           - Operational efficiency gains (food cost, labor cost)
│         KPI verification via AIDataOracle on-chain attestation.
│         Subject to same regulatory lock-up as other allocations.
│
└── 10%  Performance & Strategic Pool
          Held in Treasury Safe under multi-sig governance.
          Allocated for:
            - Performance bonuses to key personnel
            - Real estate partner incentives (e.g., Locate.ai)
            - Future strategic partnerships
            - Liquidity provision incentives
          Distribution requires multi-sig approval.

9.3 Value Accrual Drivers

ROT value is driven by five quantifiable factors:

1. Operational performance: RAA-managed metrics (food cost %, labor cost %, prime cost ratio) directly impact net operating income, which drives revenue distributions and NAV.

2. Yield generation: Revenue distributions paid in USDC create a measurable yield. For a restaurant generating $2M annual revenue at 15% net margin, the 30% investor allocation receives $90,000 annually across the investor pool.

3. Operational underwriting confidence: As the protocol accumulates on-chain performance data across restaurants and RAA cycles, the confidence interval around expected cash flows narrows, reducing perceived risk and justifying higher valuations.

4. Ecosystem expansion: As additional restaurants are tokenized, the aggregate data improves AI Engine analysis, RAA performance, and Price Oracle accuracy -- creating network effects that benefit all ROT holders.

5. Collateral utility (Phase 3+): ROTs that can be collateralized to mint RMUSD carry an implicit "convenience yield" -- the option value of being able to unlock liquidity at any time.

9.4 Illustrative Token Economics

The following is illustrative only and does not constitute a projection or guarantee.

Actual economics vary significantly based on restaurant performance, market conditions, and operational efficiency improvements driven by RAA management.

Section 10: Restaurant Debt Tokens (RDTs)

10.1 Token Characteristics

10.2 Structure

RDTs represent loans to a specific restaurant SPV, offering investors a fixed-income alternative to equity participation:

• Coupon rate: Fixed interest rate defined at issuance (e.g., 8-12% annually)
• Maturity: Defined term (e.g., 24-60 months)
• Seniority: RDT claims are senior to ROT equity claims in the revenue waterfall
• Interest payments: Paid periodically (monthly or quarterly) in USDC via InterestDistributor contract
• Principal repayment: Returned at maturity from restaurant operating cash flows

10.2.1 Securitization Terminology

RMINT maps to traditional securitization as follows:

10.3 Revenue Priority Waterfall

Revenue distribution follows a strict contractual priority enforced by smart contracts:

Restaurant Gross Revenue
│
├── 1st Priority: Debt Service (RDT Interest + Principal)
│     Paid first from revenue. RDT holders receive scheduled
│     payments before any other distribution occurs.
│
├── 2nd Priority: Essential Operations
│     Inventory procurement, labor costs, rent, utilities.
│     Managed by RAA within protocol-defined cost ceilings.
│
├── 3rd Priority: Protocol Fees
│     Platform management fees, RAA incentive settlements,
│     oracle maintenance, compliance infrastructure costs.
│
└── 4th Priority: Equity Distribution (ROT Dividends)
      Remaining profit distributed to ROT holders
      according to the 30/30/30/10 allocation.

10.4 Debt Tranching (Future)

Phase 1 implements single-tranche debt (all RDTs have equal seniority). Future phases may introduce multi-tranche structures using ERC-1400 partitions:

• Senior tranche: Lower yield, first claim on revenue, lowest risk
• Mezzanine tranche: Moderate yield, subordinate to senior, moderate risk
• Junior tranche: Highest yield, last claim, absorbs losses first (similar to Centrifuge TIN tokens)

Section 11: RMUSD Stablecoin

11.1 Phased Launch Strategy

RMUSD is a critical component of the RMINT ecosystem but requires specific preconditions before launch. The stablecoin follows a phased deployment:

11.2 Launch Prerequisites

RMUSD will not deploy until all of the following conditions are satisfied:

1. Price discovery: At least 3-5 restaurants tokenized with functioning secondary market activity or reliable oracle pricing
2. Oracle infrastructure: Chainlink Automation + custom restaurant performance data feeds operational and tested
3. Legal opinion: Independent legal analysis confirming that RMUSD (backed by security tokens) has been assessed for its own regulatory classification
4. Overcollateralization buffer: Minimum 150% collateral ratio established with 15-20% of total value locked (TVL) held in USDC or short-duration T-Bills as a liquidity buffer
5. Security audit: RMUSD contracts must pass a comprehensive security audit before any mainnet deployment

11.3 Collateral Model

RMUSD Backing
│
├── Primary Collateral: Restaurant Ownership Tokens (ROTs)
│     Deposited by ROT holders into CollateralVault
│     Valued by PriceOracle using AI Engine data + market inputs
│     Overcollateralization requirement: 150%+
│
├── Liquidity Buffer: USDC Reserves (15-20% of TVL)
│     Provides immediate redemption liquidity
│     Prevents bank-run dynamics during stress periods
│
└── Yield Layer: Short-Duration T-Bills (optional)
      Generates yield on idle reserves
      Managed through protocol treasury

11.4 Stability Mechanisms

Overcollateralization: Each RMUSD is backed by at least $1.50 in collateral value. The operational underwriting provided by RAA management enhances collateral quality by reducing the volatility of underlying cash flows.

Liquidation: When a collateral position falls below the 120% liquidation threshold, the LiquidationEngine triggers a Dutch auction, selling collateral ROTs to restore the position. A 10% liquidation penalty incentivizes borrowers to maintain healthy ratios.

Revenue Sweep ("Kill Switch"): In the event of a systemic solvency breach (aggregate Sharpe Ratio falling below a defined threshold), the protocol automatically redirects 100% of gross revenue from affected restaurants to the debt vault and stablecoin treasury. This creates an unbreakable digital lien that is superior to all equity claims.

Arbitrage: When RMUSD trades below $1.00 on secondary markets, arbitrageurs can purchase it at a discount and redeem it for $1.00 of collateral through the StabilityModule, restoring the peg.

11.5 Minting and Redemption

Mint RMUSD:
  1. ROT holder deposits ROTs into CollateralVault
  2. PriceOracle values the deposited ROTs in USD
  3. CollateralVault calculates maximum mintable RMUSD (deposit value / 1.5)
  4. User specifies desired RMUSD amount (up to max)
  5. RMUSD minted to user's wallet
  6. Stability fee accrues on the position

Redeem RMUSD:
  1. User returns RMUSD to CollateralVault
  2. Accrued stability fee is deducted
  3. Corresponding ROT collateral is released to user
  4. Returned RMUSD is burned

11.6 Key Parameters

11.7 Primary RMUSD Utility: Expansion Investment

RMUSD is not "unlock capital to park elsewhere." The primary use of RMUSD is investment in future RMINT restaurant expansion. ROT holders who mint RMUSD can commit it to the Expansion Fund to fund new restaurant tokenizations (new locations, renovations, second sites). When a new restaurant tokenizes, committers receive priority allocation in the new RMOT sale and may receive an allocation discount. This is growth participation -- not interest on RMUSD -- and is structured to comply with payment stablecoin regulations.

11.8 GENIUS Act Compliance

RMUSD is a payment/utility stablecoin. Under the GENIUS Act, payment stablecoins cannot pay interest to holders. RMUSD does not pay yield. Yield is delivered through RMOT dividends and RDT interest (both paid in USDC via RevenueDistributor and InterestDistributor), not through RMUSD. RMUSD serves as a utility token for leverage, expansion investment, and payments within the ecosystem.

Section 12: Fee Structure

12.1 Protocol Revenue Streams

12.2 Fee Allocation

Protocol fees are allocated to fund ongoing operations and ecosystem growth:

• 40% -- Protocol development and maintenance (engineering, audits, infrastructure)
• 25% -- Security reserve (audit fund, bug bounty program via Immunefi, insurance)
• 20% -- Ecosystem growth (marketing, partnerships, regulatory compliance)
• 15% -- Governance treasury (controlled by DAO in later phases)

12.3 Token Flow Summary

The complete economic cycle:

Invest (USDC) ──► Purchase ROTs/RDTs via TokenSale
                       │
Earn ◄─────────────── Revenue distributions (USDC dividends/interest)
                       │
Collateralize ────► Lock ROTs in CollateralVault
                       │
Mint ◄────────────── Receive RMUSD stablecoin
                       │
Leverage/Utilize ──► **Primary:** Commit RMUSD to Expansion Fund for new restaurant tokenizations. **Secondary:** TokenSale payment, RAA operations, DeFi, merchant payments.
                       │
Repay ─────────────► Return RMUSD + stability fee
                       │
Retrieve ◄─────────── Unlock ROT collateral

Section 13: RAA Architecture

13.1 Definition

A Risk-Aware Agent (RAA) is an autonomous or semi-autonomous software entity registered with and managed by the RMINT protocol via the Agent Coordination Contract. Each RAA operates within protocol-defined scope and on-chain lifecycle status, motivated by explicit on-chain risk/return incentives. Internally, RAAs may comprise sophisticated AI architectures including perception modules, memory, internal world models, and adaptive reasoning capabilities for determining action sequences by reasoning over world models to optimize performance against protocol incentives.

RAAs are not simple automation bots or rule-based scripts. They are AI entities capable of planning, coordination, and execution of complex operational tasks -- with the critical distinction that their behavior is directed and evaluated by the protocol's on-chain incentive system rather than by human managers.

13.2 Dual-Engine Architecture

Each restaurant's RAA system operates as a dual-role digital executive suite, optimizing for risk-adjusted returns rather than raw volume:

A. The Digital CRO (Chief Revenue Officer) -- The Revenue Engine

The CRO Engine optimizes revenue through data-driven menu engineering and pricing strategy.

Core Metric: Menu Sharpe Ratio

Applying Modern Portfolio Theory (Markowitz) to menu optimization, the CRO Engine treats each menu item as an asset in a portfolio. The Menu Sharpe Ratio is defined as:

$$S = \frac{R_p - R_f}{\sigma_p}$$

Where:

• (R_p) = Expected return of the menu portfolio (weighted average margin across all items)
• (R_f) = Risk-free rate (minimum acceptable margin floor, e.g., the restaurant's fixed cost coverage threshold)
• (\sigma_p) = Standard deviation of menu portfolio returns (volatility of margin contribution across items)

Worked Example:

Consider a menu with three item categories:

Portfolio return: (R_p = (0.72 \times 0.20) + (0.65 \times 0.50) + (0.80 \times 0.30) = 0.709) (70.9%)

Portfolio volatility (simplified): (\sigma_p \approx 0.108) (10.8%)

Risk-free threshold: (R_f = 0.55) (55% -- minimum to cover fixed costs)

Menu Sharpe Ratio: (S = \frac{0.709 - 0.55}{0.108} = 1.47)

The CRO Engine dynamically adjusts item pricing, menu mix, and promotional strategy to maximize this ratio, ensuring the stablecoin backing remains solvent even during demand shocks. A higher Sharpe Ratio indicates more stable, risk-adjusted revenue -- directly improving the quality of the cash flows that back ROT valuations and RMUSD collateral.

B. The Digital CFO (Chief Financial Officer) -- The Fiduciary Engine

The CFO Engine enforces a fiduciary mandate on expenses, functioning as an autonomous cost controller.

Core Metric: Prime Cost Efficiency

Prime Cost is defined as:

$$\text{Prime Cost %} = \frac{\text{COGS} + \text{Total Labor Cost}}{\text{Gross Revenue}} \times 100$$

The CFO Engine monitors Prime Cost in real time against a configurable underwriting threshold (e.g., 60%). When the projected Prime Cost exceeds this threshold, the CFO Engine automatically:

1. Restricts discretionary spending (marketing, non-essential procurement)
2. Initiates labor optimization protocols (shift consolidation, overtime reduction)
3. Triggers supplier renegotiation workflows (alternative vendor sourcing)
4. Escalates to the AI Engine for strategic analysis if cost pressure persists beyond 72 hours

The 60% Prime Cost ceiling is a well-established restaurant industry benchmark. Top-quartile operators maintain Prime Cost at 55-58%, while struggling operators frequently exceed 65-70%. The CFO Engine's continuous enforcement of this ceiling protects the Net Operating Income (NOI) that flows to token holders.

C. Demand-Side Intelligence

The AI Engine ingests consumer preference data and demand signals from the consumer app to produce demand-informed menu directives. Each restaurant receives daily guidance on what to cook, recommended pricing, and schedule. This bridges the gap between the CRO Engine (which optimizes given a menu) and the source of the menu -- consumer demand. The flow is:

Consumer Preferences (app) → AI Aggregation → Menu Directive → RAA Execution → Restaurant Operations

13.3 RAA Internal Architecture

Each RAA comprises the following internal modules:

┌─────────────────────────────────────────────────────────┐
│                    Risk-Aware Agent                       │
│                                                           │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────────┐  │
│  │  Perception   │  │    Memory    │  │  World Model  │  │
│  │  Module       │  │              │  │               │  │
│  │ - POS data    │  │ - Historical │  │ - Operational │  │
│  │ - Inventory   │  │   metrics    │  │   dynamics    │  │
│  │ - Labor data  │  │ - Decision   │  │ - Cost/revenue│  │
│  │ - Market data │  │   outcomes   │  │   linkages    │  │
│  │ - Customer    │  │ - Seasonal   │  │ - Demand      │  │
│  │   feedback    │  │   patterns   │  │   forecasting │  │
│  └──────┬───────┘  └──────┬───────┘  └───────┬───────┘  │
│         │                 │                   │           │
│         └─────────────────┼───────────────────┘           │
│                           ▼                               │
│                  ┌─────────────────┐                      │
│                  │ Adaptive        │                      │
│                  │ Reasoning       │                      │
│                  │ - Planning      │                      │
│                  │ - Chain-of-     │                      │
│                  │   thought       │                      │
│                  │ - Action        │                      │
│                  │   optimization  │                      │
│                  └────────┬────────┘                      │
│                           ▼                               │
│                  ┌─────────────────┐                      │
│                  │ Execution &     │                      │
│                  │ Reporting       │                      │
│                  │ - Signed reports│                      │
│                  │ - ECDSA auth    │                      │
│                  │ - Metric output │                      │
│                  └─────────────────┘                      │
│                                                           │
│  Cryptographic Identity: AlchemyServerSigner              │
│  Session Scope: functions-on-contract, erc20-transfer     │
└─────────────────────────────────────────────────────────┘

13.4 RAA Operational Scope

Each RAA's operational scope is defined at registration and enforced on-chain. Permitted operational domains include:

The scope separation ensures that revenue optimization and cost control operate as independent, cross-checking functions -- similar to the separation of duties in traditional corporate governance.

Section 14: Protocol-RAA Interaction Loop

14.1 The Continuous Management Cycle

The RMINT protocol operates through a continuous feedback loop. This cycle runs autonomously, with each iteration refining RAA behavior toward better risk-adjusted outcomes:

┌─────────────────────────────────────────────────────────────────┐
│                                                                   │
│   PROTOCOL LAYER                                                  │
│   ┌─────────────────────────────────────────────────────────┐    │
│   │ 1. Aggregate on-chain RAA metrics + market data          │    │
│   │ 2. Receive AI Engine recommendations                     │    │
│   │ 3. Update AgentCoordination contract:                    │    │
│   │    - Adjust incentive parameters                         │    │
│   │    - Update metric targets                               │    │
│   │    - Modify RAA scope if needed                          │    │
│   │ 8. Validate RAA reports (ECDSA + metric checks)          │    │
│   │ 9. Calculate and settle rewards/penalties (USDC)         │    │
│   │ 10. Update on-chain metrics, emit events                 │    │
│   └──────────────┬──────────────────────────┬────────────────┘    │
│                  │                          │                     │
│                  ▼                          ▲                     │
│   AI ENGINE                                │                     │
│   ┌─────────────────────────┐              │                     │
│   │ 4. Analyze aggregated    │              │                     │
│   │    data + RAA metrics    │              │                     │
│   │ 5. Evaluate RAA perf.    │              │                     │
│   │    against incentives    │              │                     │
│   │ 6. Recommend:            │              │                     │
│   │    - Task adjustments    │              │                     │
│   │    - Incentive changes   │              │                     │
│   │    - Metric target       │              │                     │
│   │      revisions           │              │                     │
│   └──────────────────────────┘              │                     │
│                                             │                     │
│   RAA LAYER                                 │                     │
│   ┌─────────────────────────────────────────┘────────────────┐   │
│   │ 7a. Read updated directives from AgentCoordination       │   │
│   │ 7b. Adapt operational behavior to new targets            │   │
│   │ 7c. Execute operations (procurement, pricing, scheduling)│   │
│   │ 7d. Generate ECDSA-signed performance report             │   │
│   │ 7e. Submit report to Protocol via Processor              │   │
│   └──────────────────────────────────────────────────────────┘   │
│                                                                   │
│   ◄──────────── Loop repeats continuously ──────────────►        │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘

14.2 Cycle Timing

14.3 Immutable Audit Trail

Every interaction in the cycle is recorded immutably on the Base L2 blockchain:

• RAA registration and lifecycle transitions
• Submitted operational reports with ECDSA signatures
• Metric validation results (pass/fail against incentive rules)
• Reward and penalty transactions with amounts
• AI Engine-recommended parameter changes
• Incentive rule updates with before/after values

This audit trail provides investors, regulators, and auditors with a complete, tamper-proof record of how each restaurant's operations are being managed, evaluated, and compensated.

Section 15: Operational Underwriting Model

15.1 From Static to Continuous Underwriting

Traditional restaurant investment relies on static underwriting -- a one-time assessment of the business's financial health at the point of investment, typically based on historical financial statements and management projections. This assessment is performed annually at best and provides no real-time insight into operational quality.

RMINT introduces continuous operational underwriting -- a daily, protocol-managed process where operational performance is measured, validated, and recorded on-chain in real time:

15.2 NAV Calculation Methodology

The Real-Time Net Asset Value (NAV) of each restaurant is calculated every 24 hours by ingesting data from the Closed-Loop Financial Enclosure:

$$\text{NAV} = \frac{\text{Forward-Looking Annual NOI}}{\text{Capitalization Rate}} + \text{Net Working Capital}$$

Where:

• Forward-Looking Annual NOI: Projected net operating income based on trailing 30-day RAA-reported metrics, extrapolated annually and adjusted for seasonality. Calculated as: (\text{Revenue} \times (1 - \text{Prime Cost %} - \text{Occupancy Cost %} - \text{Other OpEx %}))
• Capitalization Rate: Risk-adjusted discount rate derived from: (a) the restaurant's historical Sharpe Ratio, (b) the RAA's on-chain performance track record, (c) comparable market data, and (d) a protocol-defined floor rate
• Net Working Capital: Current assets (cash, receivables, inventory) minus current liabilities (payables, accrued expenses), as reported by the CFO Engine

15.3 How RAA Metrics Drive Valuation

The connection from RAA operational metrics to token valuation follows a deterministic chain:

RAA Operational Execution
    │
    ├── foodCostPct ──────► COGS component of NOI
    ├── laborCostPct ─────► Labor component of NOI
    ├── primeCostRatio ───► Aggregate cost efficiency
    ├── revenueProxy ─────► Top-line revenue input
    ├── wasteMetric ──────► Inventory loss deduction
    ├── sharpeRatio ──────► Capitalization rate adjustment
    └── workingCapitalDays ► Net Working Capital input
                              │
                              ▼
                    NAV Calculation (PriceOracle)
                              │
                              ▼
                    ROT Price (USD per token)
                              │
                    ┌─────────┴──────────┐
                    ▼                    ▼
          Investor Portfolio       RMUSD Collateral
          Value (dashboard)        Value (leverage capacity)

Because every input to the NAV calculation is derived from on-chain, RAA-reported, protocol-validated metrics, the valuation is verifiable -- any participant can audit the data chain from operational metric to token price.

15.4 The Closed-Loop Financial Enclosure

The integrity of operational underwriting depends on the completeness and accuracy of financial data. RMINT achieves this through the Closed-Loop Financial Enclosure:

1. Revenue origination: All customer payments flow through the RMINT mobile POS application. Diners select "Pay with RMUSD" or "Pay with USDC" -- direct wallet-to-restaurant transfer, instant settlement. Revenue is not reported to the blockchain -- it is originated on-chain. There is no physical cash register and no opportunity for off-books transactions.

2. Expense execution: All operational outflows (vendor payments, employee compensation, supply purchases) are executed via stablecoin disbursements authorized by the CFO Engine within its protocol-defined spending limits.

3. 100% custody and visibility: The protocol maintains complete custody of the financial lifecycle. Every dollar in and every dollar out is recorded immutably, creating what the white paper terms a "zero-leakage" standard.

This architecture eliminates the principal-agent problem that plagues traditional restaurant investment: there is no opportunity for management to misreport revenue, inflate expenses, or divert funds, because the protocol controls the financial infrastructure directly.

15.5 EIP-712 Reserve Proofs

Following QuillAudits RWA standards, all off-chain data flowing on-chain uses EIP-712 typed data signatures for integrity verification:

struct ReserveProof {
    uint256 timestamp;
    address assetAddress;        // RMOT contract address
    uint256 totalValueUSD;       // 18-decimal USD value
    uint256 circulatingShares;   // Total outstanding ROT supply
    bytes32 docMerkleRoot;       // Merkle root of supporting documents
}

Legal documents, financial statements, and audit reports are batched using Merkle trees: individual documents are hashed and uploaded to IPFS, the Merkle root of all document hashes is stored on-chain, and anyone can verify document inclusion using MerkleProof.verify(). This creates a cryptographically verifiable chain of custody for all supporting documentation.

Reserve Proofs support the cashflow tokenization vertical: they attest the value (totalValueUSD) and circulating supply backing ROTs, enabling PriceOracle, CollateralVault, and custodian integrations to verify collateral and reserve integrity. This design is planned for Phase 2/3; contracts do not yet implement the ReserveProof schema.

Section 16: Legal Structure

16.1 Entity Hierarchy

Each restaurant tokenization is anchored by a dedicated legal entity that isolates risk and provides the legal basis for token-based economic rights:

RMINT Holdings LLC (Delaware)
│
├── RMINT Technology LLC
│     Holds AI Engine equity stakes (30% per restaurant)
│     Platform operations, IP, engineering
│     Holds protocol IP
│
├── Restaurant A SPV LLC (Delaware Series LLC or standalone)
│     Holds legal title to restaurant assets or lease
│     Issues economic rights represented by ROT-A tokens
│     Counterparty to Operating Agreement
│     Maintains SPV bank account for fiat operations
│     On-chain reference: immutable spvEntity address in ROT contract
│
├── Restaurant B SPV LLC
│     (Same structure, fully isolated from Restaurant A)
│
└── [Additional Restaurant SPVs as portfolio expands]

16.2 SPV as Legal Anchor

Every RMOT contract contains an immutable on-chain reference to its SPV:

address public immutable spvEntity;           // SPV LLC on-chain address
string public constant PSA_HASH = "ipfs://..."; // Private Placement Memorandum hash
string public constant OA_HASH  = "ipfs://..."; // Operating Agreement hash

This creates a legally required, tamper-proof link between the digital token and the real-world legal entity. All legal documents -- the Private Placement Memorandum (PPM), Operating Agreement (OA), and Subscription Agreement -- are pinned to IPFS with their hashes stored immutably in the smart contract. Any party can verify document authenticity by comparing the IPFS document hash against the on-chain reference.

16.3 Token as Economic Right

ROTs represent economic rights in the SPV, not direct ownership of the restaurant's physical assets. This distinction is critical:

• The SPV holds legal title to restaurant assets
• ROT holders receive economic benefits (revenue distributions, appreciation) as defined in the Operating Agreement
• Governance rights, if any, are granted by the Operating Agreement -- not by token possession alone
• This structure is consistent with how traditional limited partnership interests operate, translated to a blockchain-native format

Section 17: SEC Compliance Pathway

17.1 Securities Classification

ROTs and RDTs are anticipated to be classified as securities under US federal securities law, satisfying the Howey test: investment of money in a common enterprise with the expectation of profits derived from the efforts of others (specifically, the RAA system and RMINT management).

RMINT does not seek to avoid securities classification. Instead, the platform is designed from the ground up to operate within the existing regulatory framework through valid exemptions from SEC registration.

17.2 Phased Exemption Strategy

Phase 1: Reg D 506(c) is the launch path. Key features:

• No SEC registration required
• General solicitation permitted (can publicly market the offering)
• Limited to accredited investors (verified, not self-certified)
• Form D filing with SEC within 15 days of first sale
• 12-month transfer restriction enforced on-chain via per-address lock-up

17.3 Compliance Checklist

The following requirements are enforced for every token offering:

• KYC verification: All participants verified through integrated KYC provider (Sumsub or equivalent) before on-chain identity registration
• Accredited investor verification: Independent verification via third-party service (Parallel Markets, Verify Investor) -- letter from CPA, attorney, or broker-dealer; or documented income/net worth thresholds
• On-chain identity registration: Verified wallet addresses registered in IdentityRegistry.sol with country code and claim hashes
• Transfer restrictions: 12-month lock-up enforced at the smart contract level; jurisdiction-based blocks; maximum holder counts
• Form D filing: Filed with SEC within 15 days of first sale per restaurant
• Blue Sky filings: State-level filings per state where investors reside
• Bad actor disqualification: Checks against SEC disqualification criteria
• AML program: Anti-money laundering procedures integrated into KYC workflow
• Subscription agreement: Signed by each investor (DocuSign or on-chain EIP-712 signature) before token transfer is permitted

17.4 Transfer Agent Considerations

For Reg D securities, a registered transfer agent may be required for secondary trading. Options under evaluation:

• Securitize: Transfer agent + technology provider, SEC-registered
• tZERO ATS: Alternative Trading System for compliant secondary market
• Self-administered: Higher complexity, requires legal counsel approval

Section 18: Data Privacy and Security

18.1 Three-Layer Authentication

The platform implements defense-in-depth authentication:

A compromised cookie enables UI navigation but cannot execute transactions. A compromised session cannot bypass on-chain identity checks. Only a verified, on-chain identity can participate in token transfers.

18.2 Smart Contract Security

• Audit plan: All contracts undergo professional security audit before mainnet deployment. Target auditors include QuillAudits (RWA specialty), OpenZeppelin, and Trail of Bits.
• Bug bounty: Post-audit Immunefi program with severity-based payouts (Critical: up to $50,000; High: up to $10,000)
• Multi-sig timelock: All admin operations on production contracts go through TimelockController -- 48-hour delay for parameter changes, 72-hour delay for contract upgrades, immediate for emergency pause only
• ReentrancyGuard: All financial contracts protected against reentrancy attacks
• Circuit breakers: Daily mint limits, single transfer maximums, oracle staleness thresholds

18.3 Data Privacy

• KYC documents stored in Firebase Storage with encryption at rest; access restricted to compliance team
• Sensitive personal data never stored on-chain; only hashed claim references in IdentityRegistry
• RAA operational data on-chain limited to aggregated metrics; raw restaurant data (individual transaction records, employee details) remains off-chain
• Compliance with applicable data privacy regulations (CCPA, GDPR where applicable)

Section 19: Governance Model

19.1 Progressive Decentralization

RMINT follows a progressive decentralization path for responsible token launches:

Phase 1-2: Foundation-Managed

• Core team manages protocol parameters via multi-sig (Gnosis Safe)
• 3-of-5 multi-sig required for all administrative actions
• Signatories include founder, CTO, legal counsel, and two independent advisors
• All parameter changes subject to 48-hour timelock (visible on-chain before execution)
• Community feedback solicited via governance forum but decisions remain centralized

Phase 3: Hybrid Governance

• Introduction of governance proposals via on-chain voting
• ROT holders across all restaurants can vote on protocol-level parameters (fee rates, collateralization ratios, new restaurant onboarding criteria)
• Restaurant-specific governance remains with respective ROT holders
• Core team retains veto authority on security-critical changes during transition

Phase 4+: Community DAO

• Potential introduction of a governance token for protocol-level decisions
• Core team veto authority removed; replaced by timelock + security council
• Security council (elected by token holders) retains emergency pause capability
• Full transparency: all governance proposals, votes, and outcomes recorded on-chain

19.2 Governance Scope

Section 20: Market Positioning

20.1 Competitive Comparison

RMINT is the AI-driven DeFi protocol for restaurant RWA. It operates at the intersection of RWA tokenization, AI-driven asset management, and DeFi stablecoin infrastructure. RWA tokenization + AI-managed operations + CDP-style leverage + revenue distribution = DeFi primitives with operational underwriting. No existing protocol combines all three.

20.2 RMINT Differentiation

Three capabilities distinguish RMINT from every existing RWA protocol:

1. Operational Underwriting

Existing RWA protocols tokenize assets and track financial metrics passively -- they report what happened. RMINT actively manages how operations are executed through incentivized RAAs and records the results on-chain. This is the difference between a passive index fund and an actively managed fund with verifiable, transparent performance attribution.

2. Closed-Loop Financial Enclosure

Other RWA protocols rely on external audits and self-reported financial data from asset managers. RMINT's Protocol-as-POS architecture ensures that 100% of revenue is originated on-chain and 100% of expenses are executed through protocol-controlled disbursements. There is no gap between reported and actual financials.

3. Vertical Integration of AI + DeFi + Compliance

RMINT is the only AI-driven DeFi protocol that integrates autonomous AI agent management (with on-chain lifecycle and incentives), a purpose-built stablecoin (RMUSD), and institutional-grade compliance infrastructure (ERC-3643) into a single integrated system.

20.3 Addressable Market Position

Within the $36B+ RWA tokenization market, RMINT targets the hospitality and food service segment -- a $900B US industry with virtually zero tokenized representation today. The first-mover advantage in this vertical, combined with AI-driven operational underwriting and protocol IP protection, creates a significant and defensible market position.

Section 21: Team and Leadership

21.1 Core Leadership

Balaji Kannaiyan -- Founder, CEO & CTO Technology executive with expertise in artificial intelligence, blockchain architecture, and financial technology. Protocol architect for RMINT's AI-driven autonomous agent systems for tokenized asset management. Responsible for protocol design, AI Engine architecture, and overall technical strategy.

[Detailed bio to be finalized -- education, prior roles, industry experience]

Chef Sujan Sarkar -- Co-Owner, Culinary Strategy Award-winning chef recognized with a Michelin star, bringing world-class culinary expertise and restaurant operational knowledge to the RMINT ecosystem. Responsible for culinary standards, restaurant partner selection, and operational benchmarking that informs RAA training data and performance targets.

[Detailed bio to be finalized -- Michelin credentials, restaurant portfolio, awards]

Chef Akthar Nawab -- Co-Owner, Operations Strategy Experienced restaurateur with a proven track record of scaling restaurant concepts across multiple locations. Provides operational expertise in multi-unit restaurant management, labor optimization, and supply chain efficiency -- the operational domains that RAAs are designed to optimize autonomously.

[Detailed bio to be finalized -- restaurant ventures, scale achievements, media recognition]

21.2 Advisory Board

Dr. Rishabh Mehrotra -- AI Advisor Expert in artificial intelligence and machine learning, providing guidance on AI Engine architecture, RAA model development, and performance optimization strategies.

[Detailed bio to be finalized -- academic credentials, industry experience, publications]

Dr. Jesper Kristensen -- Blockchain & DeFi Advisor Specialist in blockchain protocol design and decentralized finance, advising on smart contract architecture, stablecoin mechanics, and DeFi integration strategy.

[Detailed bio to be finalized -- academic credentials, protocol contributions, publications]

21.3 Strategic Partners

Locate.ai -- Real Estate Intelligence Provides AI-driven location analytics for restaurant site selection, informing onboarding decisions and contributing to the Performance & Strategic Pool allocation criteria.

Section 22: Roadmap

22.1 Development Phases

Phase 1: Foundation (Weeks 1-4)

• Database layer (Neon PostgreSQL + Drizzle ORM)
• Core API routes (authentication, KYC, restaurant management)
• RMOT Token + IdentityRegistry + ComplianceModule + TokenFactory (Foundry/Solidity)
• Wagmi/Viem frontend integration with contract hooks
• Firebase Storage for KYC document management
• Deploy to Base Sepolia testnet

Phase 2: Core Investment Flows (Weeks 5-8)

• KYC pipeline with provider integration (Sumsub) + on-chain identity registration
• Accredited investor verification (Parallel Markets)
• TokenSale contract + investor purchase flow (USDC on Base)
• ChefVesting contract + chef claiming flow
• Gnosis Safe treasury integration
• RevenueDistributor + revenue distribution flow
• First restaurant pilot preparation

Phase 3: DeFi Layer (Weeks 9-12)

• RMUSD stablecoin + CollateralVault deployment
• PriceOracle with AI Engine data feed integration
• LiquidationEngine + StabilityModule
• AgentCoordination contract
• AIDataOracle contract
• RAA infrastructure (Alchemy ServerSigner + Session Keys)
• Secondary market evaluation (permissioned AMM or ATS integration)

Phase 4: Audit, Legal & Launch (Weeks 13-16)

• Smart contract security audit (QuillAudits / OpenZeppelin)
• Legal structure finalization (SPV formation, PPM, subscription agreements)
• Form D filing preparation
• Base Sepolia comprehensive testing
• Base Mainnet deployment
• Pilot restaurant launch with 10-20 accredited investors
• Bug bounty program launch (Immunefi)
• Monitoring infrastructure (Tenderly, Alchemy Notify)

22.2 Post-Launch Milestones

• Q3 2026: Second and third restaurant tokenizations; crypto-native diner checkout (RMUSD/USDC); web-only wallet (wallet.rmint.com)
• Q4 2026: Reg CF integration for retail investor access
• Q1 2027: Full RAA operational deployment across portfolio
• Q2 2027: RMINT DEX or ATS integration for secondary trading
• 2027-2028: Reg A+ consideration for scale; governance DAO transition; expansion beyond US market

Section 23: Risk Factors

Investing in the RMINT ecosystem involves significant risks. Prospective investors should carefully consider the following risk factors before making any investment decision and should consult their own legal, financial, and tax advisors.

23.1 Market Risks

23.2 Operational Risks

23.3 Technology Risks

23.4 Regulatory and Legal Risks

23.5 Protocol-Specific Risks

Glossary

References

1. US Patent 12,541,765 B2, "Systems and methods for an AI-driven blockchain protocol coordinating incentivized, risk-aware autonomous operational agents for dynamic risk/return management of tokenized assets," Rmint Inc, granted Feb. 3, 2026.
2. SEC Division of Corporation Finance, "Statement on Offerings and Registrations of Securities in Crypto Asset Markets," January 2026.
3. Canton Network, "State of RWA Tokenization 2026," December 2025.
4. Crypto.com Research, "Wall Street On-Chain Part 2 – RWA Tokenisation," March 2025, https://crypto.com/en/research/rwa-tokenisation-mar-2025
5. ERC-3643 Association, "T-REX Protocol Documentation," https://docs.erc3643.org/
6. QuillAudits, "RWA System Design -- Developer Handbook," https://www.quillaudits.com/research/rwa-development/developer/rwa-system-design
7. QuillAudits, "Stablecoins: The First RWA," https://www.quillaudits.com/research/rwa-development/developer/first-rwa-stablecoins
8. MakerDAO, "The Maker Protocol White Paper," February 2020, https://makerdao.com/en/whitepaper/
9. Centrifuge, "Tokenization Documentation," https://docs.centrifuge.io/user/concepts/tokenization
10. Ondo Finance, "USDY Basics," https://docs.ondo.finance/general-access-products/usdy/basics
11. National Restaurant Association, "State of the Restaurant Industry Report," 2025.

Appendix A: Patent Summary

The RMINT protocol is protected by US Patent No. 12,541,765 B2 (granted February 3, 2026, assigned to Rmint Inc.). The patent covers: (1) AI-driven coordination of incentivized RAAs for tokenized asset management; (2) on-chain agent lifecycle and performance metrics; (3) protocol-native stablecoin for RAA settlements and leverage; (4) protocol-delegated autonomous custody; (5) continuous AI-RAA feedback loop for operational underwriting.

Appendix B: Smart Contract Interfaces

B.1 RMOTToken (ERC-3643)

// Core token functions
function transfer(address to, uint256 amount) external returns (bool)
function transferFrom(address from, address to, uint256 amount) external returns (bool)
function balanceOf(address account) external view returns (uint256)
function totalSupply() external view returns (uint256)

// Compliance
function identityRegistry() external view returns (address)
function complianceModule() external view returns (address)
function lockupExpiry(address account) external view returns (uint256)

// Emergency
function emergencyPause() external    // REGULATOR_ROLE
function forceFreeze(address, uint256) external  // COMPLIANCE_ROLE
function forceTransfer(address, address, uint256) external  // COMPLIANCE_ROLE

// Legal references
function spvEntity() external view returns (address)
function PSA_HASH() external view returns (string)
function OA_HASH() external view returns (string)

B.2 TokenFactory

function deployRestaurantToken(
    string name, string symbol, uint256 totalSupply,
    address spvAddress, bytes32 psaHash
) external returns (address rmot, address sale, address vesting, address safe)

B.3 AgentCoordination

// RAA lifecycle
function registerRAA(address raaAddr, uint256 restaurantId, uint256 scope) external
function updateLifecycleStatus(bytes32 raaId, RAAStatus newStatus) external
function getRAAStatus(bytes32 raaId) external view returns (RAAStatus)

// Incentives and metrics
function setIncentiveRules(bytes32 raaId, IncentiveRule[] rules) external
function submitReport(bytes32 raaId, PerformanceMetrics metrics, bytes signature) external
function getMetrics(bytes32 raaId) external view returns (PerformanceMetrics)

// Enums and structs
enum RAAStatus { Pending, Active, Suspended_Penalty, Suspended_Manual, Terminated }
struct PerformanceMetrics { uint256 foodCostPct; uint256 laborCostPct; uint256 primeCostRatio;
    uint256 revenueProxy; uint256 wasteMetric; uint256 customerSatScore;
    uint256 sharpeRatio; uint256 workingCapitalDays; uint256 lastUpdated; }
struct IncentiveRule { bytes32 metricId; uint256 targetValue; uint256 rewardAmount;
    uint256 penaltyAmount; bool isActive; }

[End of RMINT White Paper V6]

Copyright 2026 Rmint Inc. All rights reserved. Protected by US Patent 12,541,765 B2 and related applications.