Introduction

Blockchain enables cross-border transactions and the formation of borderless networks, and it has increasingly been applied to the domain of real-world assets (RWAs). Yet in RWAs—especially in mobility—it cannot abstract away from the local boundaries created by regulations, institutional frameworks, and commercial practices. Mobility is not merely a physical object; it is a socio-systemic entity sustained by a web of relationships and procedures among multiple stakeholders—registration, insurance, taxation, maintenance, auditing, and more.

Last year, we proposed the concept of the Mobility Oriented Account (MOA) to capture this structure from the vantage point of the user–mobility relationship. That effort sought to define mobility as an “abstract account,” but it also revealed a limitation: the concept could not fully represent the inherently multi-layered, multi-stakeholder relationships of mobility.

This paper responds to that realization by shifting the point of view. Whereas MOA attempted to define mobility from the individual entity (the account), we now seek to describe mobility from the relations themselves—the network.

Background

Given the relationships that surround it, mobility can already be understood as part of a network.

Imagine a single car on the road. It may have been manufactured by Company A, legally owned by Company B, operated by Company C, driven that day by Driver D, insured by Company E, and maintained by Company F. This intricate web of relationships is commonplace.

Mobility exists socially because diverse participants share responsibilities and provide assurance within their respective domains. Hereafter, we refer to digital trust—where these relationships are organized into a verifiable and interoperable form—as “Trust” (capitalized), and we call the concatenation of such social relationships a “Trust Chain.” We believe the value of mobility is dynamically underwritten—and in effect “shaped”—by a bundle of Trust Chains.

Mobility is not a self-contained entity belonging to a single owner; it is a web of social relationships among multiple actors, and its meaning—for whom, when, and in what context—is determined by this overall structure.

Problem

With the paradigm shifting from ownership to access-based use, mobility is being reimagined: no longer a mere means of transport, but a “mobility asset” that continuously generates intangible value. The advent of new mobility forms such as EVs and autonomous vehicles, alongside soaring vehicle prices, is fueling a global current to unlock liquidity in mobility’s value and to unbundle and reconfigure its constituent rights.

Yet any attempt to achieve this is confronted by three structural gaps.

• Level 1: The Organizational Gap

  • Vehicle registration records and vehicle and operations data remain siloed across government agencies and corporate systems, precluding their integrated use as a basis for valuation and credit assessment.

• Level 2: The Industrial Gap

  • No open, interoperable network exists to enable sustained collaboration among the multiple players in the ecosystem.

• Level 3: The National Gap

  • Disparate registration, tax, and insurance regimes across countries and regions mean that no single attestation or certificate can secure cross-border legitimacy.

These gaps are innate to mobility’s identity as an entity that is not self-contained, but rather is constituted within social systems and by a plurality of actors. By its very essence, mobility is defined by movement—across places, between people, and over borders. It inherently traverses organizational, industrial, and national lines. Can any single platform hope to capture such a transient and relational entity?

This is precisely where blockchain comes in. We posit that, for mobility’s value to circulate as it should, what is required is a network layer that seamlessly bridges these three structural gaps.

Concept

The Mobility Orchestration Network (MON) proposed in this paper is an intermediary network layer designed to orchestrate the diverse, multi-layered relationships inherent to mobility. As part of the global mobility ecosystem, it overcomes the three structural gaps with three corresponding Bridges.

MON Bridge 1: Bundling Trust

First, MON addresses the Organizational Gap. The value of a mobility asset cannot be underwritten by any single proof; it can only be secured by a bundle of Trust Chains—an aggregation of multiple proofs. MON’s role is to orchestrate the multiple streams of information that constitute these Trust Chains, thereby representing mobility on the network and digitally establishing its Trust.

The Three Proofs of Trust

• Institutional Proof

  • Elements: Vehicle title/registration records, compliance status for taxes and insurance, etc.

  • Role: To establish mobility’s legal proof of existence, backed by social and institutional systems. MON integrates these off-chain proofs into an on-chain, verifiable format.

• Technical Proof

  • Elements: VIN and type approval/CoC, OEM manufacturing data, sensor integrity, software/firmware attestations, verified maintenance events, etc.

  • Role: To certify what the object is from a technical standpoint. MON records reliable data sources (such as OEM data) on-chain to guarantee data authenticity.

• Economic Proof

  • Elements: Utilization/operational metrics, revenue history, maintenance and repair history (as operational records), etc.

  • Role: To attest to what condition the asset is in and what value it is generating. MON aggregates this dynamic information to substantiate the asset’s economic value.

Trust in a mobility asset is thus composed of three domains—the technical, the institutional, and the economic. Because each is backed by verifiable data, a mobility asset can become a trustworthy, verifiable entity across heterogeneous systems.

MON Bridge 2：Igniting the Value Cycle

Next, MON addresses the Industrial Gap. Establishing Trust makes it easier to attract capital, which in turn creates a larger cycle of capital. When the asset, finance, and service sectors are seamlessly connected, mobility’s value is reinforced and compounded within that cycle. However, MON is not a monolithic network that handles all value circulation. Rather, it is a neutral network designed with the premise of interoperating with multiple, distinct existing networks for securities, payments, insurance, lending, and mobility services. While MON serves as the ignition point for this cycle, its primary role is to orchestrate the multiple networks involved in the circulation of mobility’s value.

Three Types of Networks

• Trust Network (＝ MON): The network layer for establishing the Trust of a mobility asset. It bundles the institutional, technical, and economic proofs defined in Bridge 1 and exposes them as verifiable digital Trust.

• Capital Network: Specialized networks that handle financial activities such as lending, investment, and securitization, based on the established Trust. They enable the secure execution of financing on the network.

• Utility Network: The domain where mobility is actually operated, handling the issuance and exercise of access rights and the provision of services. The operational and state data generated here continuously reinforces the asset’s Trust and provides the basis for the next round of financing.

Even within the same region, these three domains are governed by different regulatory frameworks and thus have different network requirements. MON connects them through a common standard to enable the circulation of value.

MON Bridge 3: Connecting Ecosystems

Finally, MON addresses the National Gap. MON’s ultimate goal is to enable global value circulation without disrupting the diverse local ecosystems that already exist. The key to achieving this lies in the fact that MON is designed not as a single global platform, but as a protocol—a common set of rules.

In practice, each region has its own legal systems, financial networks, and culturally rooted services. MON respects the autonomy of these local systems to the greatest extent possible.

Local MON instances, established in each country or region, will have their own stakeholders and governance; nevertheless, they interoperate using the shared protocol as a common language of Trust. This allows different mobility ecosystems to be orchestrated through MON, enabling mobility and its associated value to move seamlessly across borders.

MON is both a network and a protocol. It functions as a specification for connecting local ecosystems worldwide, forming a global network of Trust.

Design

In the Concept chapter, we outlined how MON overcomes the organizational, industrial, and national gaps through three bridges. How, then, does MON translate the complex, real-world relationships embodied by mobility into digital assets to make that vision real?

This chapter introduces two core design principles that answer that question: the Mobility Oriented Account (MOA), which defines those relationships, and the Fungibility Ladder, which elevates them into digital assets that finance can handle.

Mobility Oriented Account (MOA)

The “bundle of Trust Chains” described in Bridge 1 is materialized on-chain as accounts that constitute the digital identity of a mobility asset. An MOA functions as a container for identity, designed to hold the multifaceted proofs a mobility asset possesses.

However, this is not a single container. To handle the different types of information appropriately, we separate the functions into two accounts with distinct roles.

• Account on the Trust Network (T-MOA): For Asset Value and Legitimacy

  • This account underpins the mobility asset’s value and legitimacy. It rigorously holds high-integrity, auditable information—such as vehicle registration, ownership records, insurance status, and audit reports—and also captures low-frequency, verified summaries of operations and revenue in a verifiable format. In short, it is the public-facing record for the financial and regulatory domains.

• Account on the Utility Network (U-MOA): For Live Operations

  • This account is the interface to the mobility asset’s operational environment. It handles the dynamic state of the Vehicle (e.g., operational status, charging status) and the real-time validation related to the Human (e.g., driving qualifications, service access rights). Data is verified, aggregated, and summarized at the point of operation; detailed logs and PII remain off-chain, with only the essential minimum bridged to the T-MOA.

Thus, the T-MOA is responsible for the trust of the Asset, while the U-MOA is responsible for the operations involving the Vehicle and Human. The two accounts are paired as mirror images, passing only essential summaries between them. Together they shape a dynamic digital identity—a snapshot that captures not only the state of the asset but also its contextual relationships at any given moment. This design reflects our prior work on the Mobility-Oriented Account, which treats mobility not merely as an object but as an entity within a broader social system.

Fungibility Ladder

As described under Bridge 2, circulating mobility’s value across industrial divides requires a transformation of its very nature. Finance treats asset value as fungible numbers, whereas mobility typically treats individual vehicles and access rights as non-fungible. To bridge this difference, MON uses tokenization to progressively alter fungibility—the Fungibility Ladder.

• Step 1: Ownership (Non-Fungible).

  • Define the right to own a mobility account as an NFT. Holding this token signifies ownership not only of the vehicle but of the entire mobility account tied to that vehicle.

• Step 2: Portfolio (Semi-Fungible).

  • Bundle multiple ownership NFTs into a portfolio with a hierarchical structure. While each mobility account is unique, focusing on specific attributes (e.g., same model, same region) allows treatment as a partially fungible set—a collection meeting defined criteria—enabling risk assessment and management at practical scale.

• Step 3: Security (Fully Fungible).

  • Value the portfolio against a widely accepted standard (e.g., fiat currency) and issue a fully fungible financial instrument—a Security Token—backed by that valuation. Thus, complex, non-fungible “relationships” are translated into standardized digital assets investors can trade with ease.

This on-chain design, composed of these two concepts, is not limited to any certain system. It is a common process for mobility tokenization that can be deployed globally. As local ecosystems adopt this design as a common specification—the protocol discussed later—the path to the global value circulation envisioned in Bridge 3 opens.

As the diagram illustrates, by ascending the Fungibility Ladder step by step from the MOA, mobility’s value crosses industrial divides as its nature transforms. MON’s core feature is precisely this design: elevating an asset into highly liquid markets while preserving the rich information of its relationships. By refining this design, we aim to freely unbundle and reconfigure the various rights associated with mobility.

Technology

In the Design chapter, we presented the MOA and the Fungibility Ladder as MON’s core design principles. What technical challenges must be overcome to realize these principles? MON’s technical design begins with three questions:

• Origin of Trust: How can we technically guarantee assurance at the portfolio level—a portfolio composed of vehicles, each with an MOA?

• Circulation of Value: How can we enable secure interoperability among heterogeneous networks (Trust / Capital / Utility) as an asset ascends the Fungibility Ladder?

• Extensibility of Components: How should core components such as MOAs and portfolios be architected so they can accommodate new rights and services over time?

We now lay out our technical approach.

1. Identity: Digital Proof of Existence as the Origin of Trust

All trust begins with the ability to prove who or what something is. MON assigns a blockchain-verifiable digital identity to physical vehicles, with the MOA serving as the container that aggregates their information.

The first step is to capture the most fundamental right—ownership—in digital form. We propose that, at the moment of manufacture, the OEM issues the vehicle’s ownership as an NFT (Non-Fungible Token). This NFT is not merely a digital asset; it is the first official record that establishes the vehicle’s unique identity, and it is inextricably linked to its MOA.

To this MOA, attested datasets are associated in sequence—e.g., registration information from public authorities and manufacturing data from the OEM. In this way, a tamper-evident identity anchored on-chain is formed, linking the physical asset to its digital information and providing the foundation for sharing Trust across the ecosystem.

When a vehicle is manufactured, an account for managing its ownership and identity is registered on-chain. As ownership transfers—to a dealer, an end user, or a fund—events across the vehicle’s lifecycle (maintenance, changes in operational status, and more) are continuously recorded to this account. Even remote stakeholders, such as investors, can thus verify the asset’s condition at any time.

2. Multi-chain: Division of Roles to Support Value Circulation

MON’s architecture rests on collaboration across three functional domains—Trust, Capital, and Utility. To realize this technically, MON assumes a multi-chain architecture across two layers.

Layer 1: Intra-regional interoperability

Within a single country or region, numerous independent networks with different technologies and governance models will exist.

• Capital networks: security-token platforms, DeFi protocols, payment networks, etc.

• Utility networks: connected-service platforms, ride-hailing operator systems, V2G/VPP platforms, etc.

The local MON (Trust Network) must function as a neutral interoperability layer that connects these heterogeneous networks.

Layer 2: Inter-regional interoperability

MON itself is not a single global network; it is a protocol designed for local deployment, respecting each region’s laws and ecosystems (e.g., a MON for Japan, a MON for the United States). To enable cross-border used-vehicle trade and global capital formation into regional fleets, local MON instances must interoperate with each other.

Delivering this two-layer collaboration securely and seamlessly is why MON adopts a multi-chain approach. Choosing a high-assurance cross-chain messaging protocol is therefore critical as the technical backbone.

3. Composability: A “Combine, Don’t Rebuild” Philosophy for Extensibility

Mobility’s value is not static. Fleets and their vehicles, changing owners and users, and intricate rights arrangements shift with time and use cases. Rather than building a proprietary, closed system, MON emphasizes composability—combining proven, open standards like LEGO-style blocks:

• ERC-721 — represent vehicle ownership as NFTs.

• ERC-7401 — express portfolios/hierarchies via parent-governed NFT nesting.

• ERC-6551 — bind an MOA’s address to its ownership NFT (token-bound accounts).

• ERC-4337 — make MOA execution/verification flexible (account abstraction, alt mempool).

• ERC-7579 — modularize MOA functionality (minimal modular smart accounts).

• ERC-735 — store verifiable claims in the MOA (Claim Holder).

• ERC-3643 — circulate regulation-compliant securities/currencies (T-REX).

The key point is that composing these standards enables flexible expression of complex rights and degrees of fungibility. Building from loosely coupled components with well-specified interfaces preserves extensibility for unforeseen change. Through this composability, MON aims a flexible protocol that can keep pace with the evolution of future mobility ecosystems.

Prototype Architecture

To translate the concepts from the Design and Technology chapters into working code and validate their potential, we have designed a prototype. This is not an attempt to implement MON’s grand vision in one shot; rather, it is a sandbox intended for deployment in a single region under specific conditions.

The prototype consists of four components:

• Avalanche L1 Blockchain

• Interchain Messaging Protocol

• Identity Service

• Trust Gateway

Avalanche L1 Blockchain: The Stage for Building the Ecosystem

For this prototype, we selected Avalanche as MON’s foundational layer. Avalanche features high-speed, low-latency consensus and a multi-chain architecture of purpose-built chains. Its primary public chains include the C-Chain for EVM-compatible smart contracts, the P-Chain for staking and validator management, and the X-Chain for asset creation and transfers. Furthermore, it is possible to deploy custom L1s (formerly “Subnets”), which can be configured as either public or private to build an optimal L1 blockchain tailored to the desired service. All EVM-based Avalanche L1s—including the public C-Chain and any custom EVM L1s—can be connected via Avalanche Interchain Messaging (ICM), which uses the Teleporter contracts and the Warp precompile to enable secure, low-latency cross-chain transfer of tokens and data, facilitating integrated application design.

We chose Avalanche because its design centered on multiple L1s (formerly Subnets), its fast finality, and its native ICM align with MON’s philosophy of building locally, collaborating globally.

In this prototype, we assume four L1-style Subnets on Avalanche, each with a specific role:

These are illustrative; depending on the use case, functions can be consolidated or further subdivided. Avalanche’s flexible architecture can support such complex topologies.

Interchain Messaging Protocol: The Common Language Connecting Networks

Independent networks need a secure and reliable way to “converse.” This is especially critical for Delivery-versus-Payment (DvP) transactions, where asset delivery and payment must finalize atomically.

Representative interchain messaging options include:

For this prototype, we adopt Avalanche ICM due to its native fit and ease of implementation. Contract developers can integrate cross-network interactions simply and safely—almost as if invoking functions on the same network.

Avalanche ICM works as follows. Calling ITeleporterMessenger.sendCrossChainMessage in the source contract enqueues a message on-chain. An off-chain component—the Relayer—then retrieves this message. The Relayer submits it to the Teleporter (Messenger) contract on the destination chain, which in turn calls ITeleporterReceiver.receiveTeleporterMessage(...) on the destination contract. Developers can achieve secure cross-chain communication by deploying contracts that implement the ITeleporterMessenger interface (sender) and the ITeleporterReceiver interface (receiver). As long as these interfaces are adhered to, other logic can be freely implemented to meet project requirements. Throughout the process, Avalanche’s native EVM extension, the Warp Precompile, is invoked to perform security procedures such as cross-chain message verification and mutual authentication.

Identity Service: The Information Hub Connecting Digital and Physical

How can a digital asset on a blockchain be trusted as linked to a real-world object? The Identity Service addresses this RWA-common challenge by acting as an information hub between digital and physical domains.

For privacy and scalability, not all information can live on-chain. However, by making selected fields—or their hashes—accessible on-chain, one can always verify current status, while owners access richer detail off-chain.

Its three main functions are:

This mechanism preserves confidentiality while enabling anyone to verify essential asset state on-chain.

Trust Gateway: Bringing Institutional/Social Trust On-Chain

Trust sources handled by MON do not originate on blockchain alone. How can off-chain trust—e.g., vehicle registration data rooted in existing systems—be bridged securely into the digital realm? The Trust Gateway performs this role.

The approaches to achieving this have the following pros and cons:

Each option involves trade-offs; no perfect solution exists today. For this prototype we adopt the trusted-intermediary approach to simplify verification, while aiming over time for more decentralized designs that better balance privacy and transparency.

Contracts

In the previous chapter, we presented the overall picture of the sandbox system for validating the MON concept. This chapter details the blueprint of the smart contracts that form its core.

MON's design philosophy, particularly the Fungibility Ladder, is realized not by a single contract, but through the collaboration of a group of contracts with distinct roles. This structure forms a hierarchical architecture based on the MobilityOrientedAccount, which defines the digital identity of a mobility asset, with the VehicleOwnership contract representing its ownership, and the AssetPortfolio bundling multiple ownership rights.

To understand this structure, we will begin by explaining the foundational contract of the entire system: the MobilityOrientedAccount.

1. MobilityOrientedAccount (MOA)

The MOA is the foundation of the MON architecture and the most critical smart contract for aggregating a vehicle's digital identity. It is more than just a data store. To enable a complex Real-World Asset (RWA) like mobility to function autonomously on the blockchain, the MOA has the following three characteristics:

• Smart Account: Enables mobility to act as an autonomous agent that behaves according to rules.

• Mirror Architecture: Reconciles the conflicting requirements of real-time operational immediacy and ledger finality by using two accounts with distinct roles.

• Modular Design: Possesses an extensible structure that can keep pace with future changes in requirements.

MOA as a Smart Account: The Autonomous Agent

Mobility needs to be able to autonomously execute programmatically defined behaviors according to the situation, such as verifying usage rights, performing pre-start checks, summarizing metering data, and updating its state after receiving a cross-chain message.

To achieve this autonomy, the MOA is designed as a smart account.

• Implementation: The MOA acts as a smart account compliant with ERC-4337 and is permanently bound to a VehicleOwnership (or, where applicable, AssetPortfolio) NFT via ERC-6551. This allows the MOA to function as a "dedicated account tied to a vehicle," supporting advanced operational requirements like gas sponsorship via a Paymaster, multi-sig, and session keys.

• Automatic Rights Resolution: Authorization is determined by deriving the top-level root owner via ownerOf (a function that recursively traverses the parent-child relationships of ERC-7401). Even if the ownership of a VehicleOwnership/AssetPortfolio changes, no additional migration process is needed on the MOA side; the new root owner is automatically recognized as the authorized party during the next verification.

Mirror Architecture: The Dual-Phase Structure of Field and Ledger

The Mirror MOA refers to an implementation where two MOAs (a U-MOA and a T-MOA), bound to the same VehicleOwnership NFT via ERC-6551, are instantiated on separate networks and linked via Avalanche ICM. The key here is that this is not a mere "view switching," but the separate operation of two accounts with different responsibilities.

The technical key to this architecture is a mechanism to deterministically generate two account addresses with different roles from a single NFT, in a way that is verifiable by anyone.

This is achieved by combining the CREATE2-based account registry provided by ERC-6551 with role identifiers for the MOA (ROLE_TRUST / ROLE_UTILITY). Specifically, by including this role identifier in the salt used for address calculation, two distinct MOA addresses can be derived from the same NFT.

The following code is a minimal implementation example of this address calculation logic.

// Minimal 6551 binding for Mirror MOA (T / U)

// Address resolution for Mirror MOA using ERC-6551 registry
interface IAccountRegistry6551 {
    function account(address impl, uint256 chainId,
                     address nft, uint256 id, bytes32 salt,
                     bytes calldata initData) external view returns (address);
                    
    // ... createAccount function
}

// Role identifiers to distinguish between T-MOA and U-MOA
bytes32 constant ROLE_TRUST   = keccak256("TRUST");
bytes32 constant ROLE_UTILITY = keccak256("UTILITY");

// Function to calculate role-specific MOA address from the same NFT
function moaAddress(
    IAccountRegistry6551 reg,
    address impl,
    uint256 targetChainId,
    address voNft,
    uint256 voId,
    bytes32 role // Specify ROLE_TRUST or ROLE_UTILITY
) internal view returns (address) {
    // Generate a unique salt from chainId, NFT address, TokenID, and the "role"
    bytes32 salt = keccak256(abi.encode(targetChainId, voNft, voId, role));
    return reg.account(impl, targetChainId, voNft, voId, salt, "");
}

/*
 * === Example Usage ===
 * address tMoa = moaAddress(registry, implementation, HOME_CHAIN_ID, voNft, voId, ROLE_TRUST);
 * address uMoa = moaAddress(registry, implementation, HOME_CHAIN_ID, voNft, voId, ROLE_UTILITY);
 */

This mechanism allows the T-MOA and U-MOA addresses corresponding to a specific VehicleOwnership NFT to be deterministically derived and verified by any third party through recalculation.

Each MOA has a clearly separated role:

• U-MOA (Utility-side / L1-C): Pre-processing Node. Handles real-time processing of high-frequency events like driver qualification checks, operational logs, and charging/discharging data. It is responsible for verification → aggregation → summarization (hash / Merkle / ZKP). Originals containing PII or detailed logs remain on the Utility side and off-chain to ensure privacy.

  • Handling User Credentials: "Human" credentials like driver's licenses are held in the user's own account. The U-MOA only verifies and summarizes their validity through selective disclosure or ZK proofs (PII is not brought to the Trust side).

  • Minimal Profile: Persistent storage of ERC-735 claims in the U-MOA is not mandatory. In a minimal configuration, it specializes in verification, summarization, and ICM dispatch, while the T-MOA handles finalized storage.

• T-MOA (Trust-side / L1-B): Ledger for Rights Finalization. Accepts only the verified summaries sent from the U-MOA via ICM and finalizes them as ERC-735 claims. The claims are maintained as a tamper-evident (append-only) record, with revocations/corrections handled by reference. Asset valuation and securitization are performed based on this finalized data on the Trust side.

This dual-phase structure aims to simultaneously satisfy the high throughput required in the field and the stringency and auditability demanded by capital markets.

Modular Design: Extensibility for Future Demands

Regulations, services, and cryptographic/privacy technologies are constantly changing. The MOA uses a modular design based on ERC-7579, allowing its functionality to be replaced or extended while maintaining the same address.

Main Modules:

• Validator Module: Handles authorization based on ownerOf (with ERC-7401 recursion), EIP-1271 signature verification, session keys, policy-based approvals, multi-sig, etc.

• Executor / Hook Module: Isolates post-processing tasks such as aggregation, normalization, and notification after an ICM receipt; integration with AssetPortfolio; and updates to availability KPIs.

• Fallback Module: Serves as an extension point for adding functions later. Core functionalities like the APIs for the ERC-735 Claim Holder and ICM reception can also be provided and updated as modules.

Note: ERC-735 is a community-proposed standard (draft stage), but we have adopted it as it fits the practical requirements for storing verifiable claims and referencing their revocation.

2. VehicleOwnership

The VehicleOwnership is a simple ERC-721 token representing the ownership right (legal title or an equivalent right) to a specific vehicle. To connect mobility as an asset to existing finance and lay the groundwork for securitization, a starting point of ownership that is assertible against third parties is required. This token provides an interface compliant with standard specifications for that purpose.

• Standard and Minimum Requirements: The minimum requirement for a mobility asset is to possess the concept of ownership (ownerOf) and transferability (transferFrom/safeTransferFrom) as defined by ERC-721.

• Issuing Authority: It is expected to be minted by an OEM, registration authority, or a Trust Gateway at the time of manufacture or first registration (selected according to local regulations).

• 1:1 Invariant: One VehicleOwnership per vehicle. Changes in title are expressed through transfers, and the token is burned upon decommissioning or scrapping.

• Relationship with MOA: Vehicle attributes and attestations are aggregated not in this token, but in the MobilityOrientedAccount. The VehicleOwnership and MOA are permanently bound via ERC-6551 and are consistently referenced, including from the subsequent AssetPortfolio.

In essence, the VehicleOwnership token bestows the abstract concept of "ownership" upon the physical vehicle, providing a thin layer—a Hardware Abstraction Layer, so to speak—for secure access from the financial side. Since attribute data and operational attestations are held by the MOA, this token functions as a simple and highly interoperable "root of ownership."

3. AssetPortfolio

The AssetPortfolio functions as a parent NFT that bundles one or more VehicleOwnership NFTs. Aggregating (nesting) individual ownership tokens into a single portfolio has clear technical and financial rationales.

• Technical Aspect: Since multiple NFTs can be treated as a single unit, it simplifies complex operations like atomic swaps and enhances interoperability with other protocols.

• Financial Aspect: It enables a securities issuer to value and report to investors at the portfolio level, rather than on a per-vehicle basis.

To achieve this, the AssetPortfolio is equipped with a parent-child nesting function for NFTs and reporting capabilities for capital markets.

Parent-Child Nesting: Adopting ERC-7401

ERC-7401: Parent-Governed Non-Fungible Tokens is adopted as the technical standard for enabling an AssetPortfolio to own (nest) VehicleOwnership tokens. This allows for the on-chain representation of NFT parent-child relationships.

In ERC-7401, ownerOf recursively traverses the hierarchy to return the root owner (the top-level owner address that is not an NFT), while the immediate parent NFT is retrieved with directOwnerOf. Therefore, when an MOA performs an authorization check, it can uniquely determine the ultimate rights holder by calling ownerOf(tokenId) on either the VehicleOwnership or AssetPortfolio, regardless of nesting depth.

Below is an excerpt from a reference library showing the behavior of ERC-7401.

/// Minimal view of ERC-7401 behavior
interface IERC7401 {
    /// Returns the root (top-level, non-NFT) owner
    function ownerOf(uint256 tokenId) external view returns (address);

    /// Returns the immediate parent NFT (contract, tokenId)
    function directOwnerOf(uint256 tokenId)
        external
        view
        returns (address parentContract, uint256 parentTokenId);
        
    /// ... and more functions
}

The MOA's Validator module, following ERC-7401, uses the return value of ownerOf (the root owner) to always identify the legitimate rights holder, even in deeply nested hierarchies.

Reporting Functions: The Interface with Capital Markets

As an information disclosure window for capital markets, the AssetPortfolio implements at least the following two reporting functions.

1. getAvailability() / setAvailability() Manages the "number of available vehicles / total vehicles" within the portfolio.

   • Data Source: The availability flag references the claims finalized and recorded in each vehicle's T-MOA.

   • Optimization: To avoid high gas costs from loop calculations, a cached counter is maintained on-chain and updated asynchronously via events or an oracle (setAvailability).

2. getAssetValue() / setAssetValue() Manages the portfolio's valuation and the timestamp of that valuation.

   • Access Control: To ensure reliability, this value can only be written by a designated auditing or valuation oracle via the setAssetValue function.

   • Robustness: A timestamp check (require(asOfDate >= v.asOfDate)) is performed to prevent overwriting with stale information.

contract AssetPortfolio /* ... */ {
    event AssetValueSet(uint256 indexed id, uint256 amount, uint64 asOfDate);
    event AvailabilitySet(uint256 indexed id, uint256 available, uint256 total);
    event ChildAdded(address indexed child, uint256 indexed childId);
    event ChildRemoved(address indexed child, uint256 indexed childId);

    function getAvailability(uint256 id)
        external view returns (uint256 available, uint256 total);

    function setAvailability(uint256 id, uint256 available, uint256 total)
        external /* onlyRole(REPORTER_ROLE) */;

    function getAssetValue(uint256 id)
        external view returns (uint256 amount, uint64 asOfDate);

    function setAssetValue(uint256 id, uint256 amount, uint64 asOfDate)
        external /* onlyRole(REPORTER_ROLE) */;
}

Division of Roles between On-chain and Off-chain

The information provided by the AssetPortfolio is based on an appropriate division of roles between on-chain and off-chain components.

• On-chain: Availability counters, asset value snapshots, ownership hierarchy.

• Off-chain: Detailed asset valuations using market prices and risk models; original operational logs handled by the U-MOA.

• On-chain Bridge: Information flows in sequence from the U-MOA → (ICM) → T-MOA → to claims that are referenceable by the AssetPortfolio.

4. SecurityToken / StableCoin

The contracts discussed in this section are assumed to be deployed on a separate network (a Capital Network), distinct from MON. MON provides the asset-side Trust (via T-MOA/AssetPortfolio); the issuance, transfer, and regulatory compliance of tokens are the responsibility of the partner networks.

Roles and Compliant Standards

The final choice of standards depends on the operational requirements of the jurisdiction and the issuer. MON is neutral and only defines the integration interface that connects assets and tokens.

• Security Token (ST): An ERC-20 compatible token issued against the backing of the bundled ownership rights in an AssetPortfolio and distributed to investors. Transfers are subject to compliance requirements (KYC/AML, accredited investor status, lockups, etc.), for which we assume compliance with ERC-3643 (T-REX). A key feature of ERC-3643 is its ability to enforce regulations on-chain through pre-transfer checks that combine an identity registry with compliance rules.

• Stable Coin (SC): Used as the payment rail for investment, distribution, and settlement. A standard ERC-20 is sufficient if transfer controls are not needed, but ERC-3643 can be adopted if they are.

Integration Interface with MON

• Asset Backing Verification: The ST issuing contract holds the token ID of the AssetPortfolio that serves as the value backing. Investors and auditors can trace back from the ST to the AssetPortfolio and directly reference and verify the finalized data (the Trust) provided by MON via getAssetValue() and getAvailability().

• Disclosure Linkage: The summarized claims for operational performance and revenue, aggregated from the U-MOA and finalized in the T-MOA, serve as a reliable data source to support the issuer's disclosure obligations. If required, this finalized data can be used to trigger events or update metadata on the ST side automatically.

Advanced Integration Functions

• Privacy Enhancement (e.g., Avalanche eERC): It is possible to adopt implementations that encrypt balances and transfer amounts (e.g., Avalanche's eERC) while maintaining compliance verification (who can transact). Zero-knowledge proofs verify the legitimacy of transactions, and data can be disclosed to auditors via a view key, achieving "privacy that is compatible with compliance."

• 3-way DvP (Delivery-vs-Payment-vs-Title): A mechanism for atomically executing the three-way exchange of funds (SC), securities (ST), and the underlying asset ownership (AssetPortfolio). Cross-chain coordination via ICM minimizes counterparty risk and the need for short-term bridge financing by ensuring that the entire transaction is rolled back if any single part fails.

• Token Lifecycle Automation: MON's finalized data can be used as a trigger to automate token operations.

  • Distribution: Automatically execute dividend payments in SC based on the revenue summaries recorded in the T-MOA.

  • Redemption: Automatically trigger the burning of STs and the return of SCs based on events such as the sale or collateral release of the AssetPortfolio.

Use Cases

MON aims to create a world where the necessary capital flows appropriately into mobility. The adoption of battery electric vehicles (BEVs) and autonomous vehicles requires large-scale investment, making it essential to verify asset authenticity and value across national and corporate borders. MON provides the mechanism for this by aggregating institutional, technical, and economic verifiable claims into the MOA, enabling cross-industry interoperability and igniting a cycle of capital.

The following four cases—centered on the linkage between finance and mobility—illustrate how MON functions to address the specific challenges in each scenario.

(1) BEV Adoption in Emerging Markets

Challenge. While BEV adoption is encouraged by policy in many emerging markets, attracting foreign capital is critical given high vehicle prices. Verifying the existence, condition, and revenue-generating capacity of fleets operating in remote locations is difficult, often stalling investment decisions.
MON’s Contribution. MON bundles institutional claims (e.g., registration, ownership, insurance compliance), technical claims (e.g., VIN, OEM provenance, battery state-of-health/SoH), and economic claims (e.g., operational logs, revenue performance) into the MOA and surfaces them as a fleet-level portfolio. The portfolio can be tokenized into regulation-compliant security tokens as needed, drawing capital from Capital Networks beyond the region. As operations proceed, data from the Utility Network continuously feeds back into MON, dynamically updating Trust, reducing due-diligence burden, and lowering the cost of capital.

(2) Deploying Robo-Taxis in Local Regions

Challenge. The deployment of Level-4 robo-taxis requires significant upfront investment and evidence of demand. Limited access to objective data on demand, operations, and safety impedes sustained investment.
MON’s Contribution. Alongside institutional claims (operating permits, insurance compliance), MON integrates technical/safety evidence (autonomous-stack versions, safety event logs) and economic records (operations/revenue) into a regional portfolio. This enables presentation as a highly transparent investment opportunity to municipalities, regional banks, and infrastructure investors. The portfolio can be tokenized into security tokens (STs) to mobilize capital. As operations expand, Utility Network performance is reflected back into Trust, facilitating evaluation and additional financing based on region-specific results.

(3) Monetizing the Energy-Storage Value of BEV Fleets

Challenge. Beyond mobility services, BEVs can provide grid value via V2G/VPP; however, a framework to assess vehicle value + storage value + environmental value in an integrated manner is lacking.
MON’s Contribution. MON layers technical claims (battery passports, SoH), economic claims (charge/discharge records, market revenues), and environmental claims (proofs of green-energy origin) onto each vehicle’s MOA and visualizes them as an integrated portfolio. By tokenizing this portfolio into STs, financing for capex and fleet expansion can be advanced, backed by combined mobility and storage revenues. Actual operating results are continuously reflected in MON, allowing ongoing updates to valuation.

(4) Logistics Efficiency and Green Transition

Challenge. Scaling logistics (larger fleets, automation) and decarbonizing energy sources require massive investment. Verification is demanded for both environmental value (e.g., hydrogen origin/“greenness”) and commercial value (operational performance).
MON’s Contribution. MON layers institutional claims (vehicle registration, compliance), technical claims (fuel origin certificates, vehicle telemetry), and economic claims (load factor, deadhead rate, CO₂ reduction, revenue) to present an ESG-oriented portfolio. Through a structured-finance framework with class-specific rules, homogeneous fleets can be bundled, disclosed to investors, and securitized as ESG bonds or security tokens as needed. Moreover, initiatives on the Utility Network—such as joint deliveries—are reflected into Trust, improving quantification of transport efficiency and emissions reduction and increasing attractiveness for ESG investment.

Outlook and Next Steps

Throughout this paper, we have argued for the Mobility Orchestration Network (MON) as a means to maximize the value generated by mobility amid structural change and to enable the appropriate circulation of capital. We have also identified the requirements for implementation and presented the design of a prototype currently under development. That said, many challenges remain before the MON concept can mature into a network that functions in the real world.

Connecting to Diverse Networks

By establishing Trust, MON enables the seamless orchestration of Capital Networks for finance and Utility Networks for mobility services. To realize this, we must interoperate with a variety of Capital and Utility Networks and internalize what the broader ecosystem requires. From a medium- to long-term perspective, we will actively collaborate with security-token issuance services, tokenization platforms, and mobility service providers willing to interoperate with MON.

Expanding Technological Options

Many alternatives to the technologies and standards used in this prototype are rapidly evolving. While Avalanche fit the prototype’s requirements, MON’s principles call for experimentation across base-layer blockchains, cross-chain messaging protocols, and oracle/Trust-Gateway approaches to determine the best fit. Privacy remains a priority; we will continue to learn from state-of-the-art cryptography such as zero-knowledge proofs and privacy-preserving tokens. We remain technology-agnostic and will accelerate collaboration with a diverse developer community.

Contributing to Standards Communities

This prototype builds on community-proposed standards. Such standardization is indispensable for the composability and interoperability MON seeks. We will feed back lessons from the prototype, and where gaps exist, proactively propose new specifications. The stability of standards is critical for enterprises entering the on-chain world; for standards to flourish, industry must understand and support the work of these communities.

About Toyota Blockchain Lab

Established in 2019, Toyota Blockchain Lab is the Toyota Group’s blockchain R&D hub. We started with product/data authenticity and traceability; now we build at the intersection of finance × mobility × Web3. To realize Mobility 3.0—mobility as social infrastructure—we stitch together the systems around mobility. Our core constructs are MOA, the identity layer, and MON, a protocol that orchestrates specialized networks. We design, build, and run—end to end—pairing modern cryptography and decentralized architecture with compliant legal, security, and governance practices. With a broad partner ecosystem, we drive standardization and open innovation for next-gen mobility.