MPAI started addressing “metaverse” as a subject for standardisation in the early days of 2023 as an objective per se but also as an opportunity to integrate a plurality of technologies for which it had developed or was developing standards. After developing two Technical Reports exploring the issues, MPAI developed the MPAI Metaverse Model – Architecture (MMM-ARC) standard. This was followed by the MPAI Metaverse Model – Technologies (MMM-TEC) standards of which MPAI-66 has recently published Version 2.2.
In three years MPAI has invested significant resources in this project achieving important results. The initial MMM notions included things (Items) and beings (Processes) operating in a metaverse instance (M-Instance) under the responsibility of a human in conformity with the Rules of the M-Instance. Processes hold Rights on Items and Processes and can thus perform Actions on them. A Process may request another Process (e.g., a Service) to perform Actions on its behalf by issuing a Process Action. Twenty-eight Actions have been specified in terms of semantics, and more than 100 Items have been specified in terms of syntax (JSON Schema) and semantics. More than 50% of Items currently identified by MMM-TEC are defined by other MPAI Standards. The notion of Qualifier – metadata giving information such as format of an Item – has been fully adopted and integrated with the notion of a “Convert Service” to facilitate M-Instance interoperability as MMM-TEC does not impose any particular technology, such as for media.
MMM-TEC V2.2 inherits all the enabling technologies from preceding versions and enhances them with new technologies that provide full support for the establishment of virtual economies in an M-Instance.
This is the full list of finance-related Data Types specified by V2.2:
| Acronym | Name | JSON | Acronym | Name | JSON |
| MMM-ASS | Asset | X | MMM-MKC | Market Classes | X |
| MMM-CTO | Contract Object | X | MMM-PRV | Provenance | X |
| MMM-CUO | Currency Object | X | MMM-SPM | Service Pricing Model | X |
| MMM-FBR | Fault Behaviour Report | X | MMM-SCT | Simple Contract | X |
| MMM-FDR | Fault Detection Report | X | MMM-TRA | Transaction | X |
| MMM-FER | Financial Error Report | X | MMM-VAL | Value | X |
| MMM-LIC | Licence | X | MMM-VMI | Value Metadata IDs | X |
| MMM-MPI | Marketplace Policy IDs | X | MMM-WAL | Wallet | X |
All MPAI specification entities – Data, AI Modules, and AI Workflows – are identified by six characters. The first three identify the standard (MMM in the case of Metaverse) and the remaining three the specific entity within that standard. Each entity (Data Types in this case) is specified in natural language on a specific web page (the table provides the links) and in a JSON Schema that may reference a Qualifier.
MPAI defines a “Simple Contract” that provides basic functionalities but also defines a Contract Object. The term “Object” indicates that the entity is composed of Data and a Qualifier. In the case of Contract, the Data are the contract, but the Qualifier specifies how to interpret the Data. MPAI acts as a Registration Authority that receives requests for new Contract Types not currently included in the Contract Qualifier.
The Asset Data Type is the key element of MMM-TEC finance. As for all MPAI Data Types, the natural language specification is subdivided into Definition (what the Data Type is for), Functional Requirements (the functionalities offered by the Data Type), Syntax (the JSON Schema), Semantics (the meaning of the data carried by an Asset Data Type instance), and Conformance Testing (how to test that an Asset Data Type instance is a correct implementation of the specification).
Let’s analyse what is inside the Asset Data Type, i.e., its semantics.
| Label | Description |
| Header | Asset Header – Standard “MMM-ASS.Vx.y” |
| M-InstanceID | Identifier of M-Instance. |
| M-Environment | Identifier of a relevant Environment. |
| AssetID | Identifier of the Asset. |
| SourceItemID | Identifier of the Source Item that spawned the Asset. |
| AssetDate | Timestamp of Asset creation. |
| Capabilities | Declared process Capabilities and Rights (the Asset carries information on who holds which Rights to the Asset). |
| Provenance | Information about the Asset provenance through a value chain. |
| MarketClass | One of a set of categories of assets, rights, services, and experiences exchanged. |
| ValueMetadata | Identifiers used to tag values associated with transactional or functional attributes. |
| CurrencyID | Allowed currency type for pricing. |
| ServicePricingModel | Rules, parameters, and conditions under which the Asset is offered, billed, chosen, settled, and accessed. |
| MarketplacePolicyID | Identifier of the policy applied to listing, transaction, or operation of an Asset (Item or Service). |
| DataExchangeMetadata | Metadata ensuring correct transfer of information from Source to Destination. |
| Trace | Identity of the Process producing the Asset and its Time of production. |
| DescrMetadata | Free-text metadata. |
Of the elements in the first column, we will now concentrate on Service Pricing Model (SPM), a Data Type of high importance for establishing a virtual economy in an M-Instance. The following semantic table is much more structured, and so the specification of the different service pricing models has been simplified. The Asset Posting, Chosen, and Settlement parts retain the full details. The SPM Status label is used to signal the intermediate or final status of the Service Pricing Model.
| Label | Description |
| Header | Service Pricing Model Header – Standard “MMM‑SPM‑Vx.y”. |
| MInstanceID | Identifier of the M‑Instance. |
| MEnvironmentID | Identifier of the M‑Environment. |
| SPMID | Identifier of this Service Pricing Model instance. |
| SPMContext | Whether this SPM describes a Service or an AssetPosting. |
| SPMTime | Reference time for this SPM (OSD/V1.5 Time). |
| ModelType | Primary pricing model: OneTime, Subscription, PayPerUse, PayPerTime, Freemium, Tiered, AdSupported, Hybrid (when combining multiple models). |
| CurrencyObject | The currency for prices and values used in this SPM. |
| Models | |
| ├─ OneTime | One‑time purchase model. |
| ├─ Subscription | Subscription pricing data. |
| ├─ PayPerUse | Usage‑based (metered) pricing. |
| ├─ PayPerTime | Time‑window pricing. |
| ├─ Freemium | Freemium model. |
| ├─ Tiered | Tiered plan. |
| ├─ AdSupported | Ad‑supported access. |
| ├─ Discounts[] | Discount definitions. |
| └─ Hybrid[] | Hybrid composition (combining sections). |
| AssetPosting | Data for posting an Asset under this SPM. |
| ├─ AssetID | ID of the asset being posted. |
| ├─ LicenceTerms | Terms under which the asset is licensed. |
| ├─ SenderPreValue | Value before transaction. |
| ├─ SenderPostValue | Value after transaction. |
| ├─ ReceiverPostValue | Value after transaction for receiver. |
| ├─ ValueToSender | Final value to sender. |
| ├─ SenderWalletID | Wallet of sender. |
| ├─ ServiceProviderWalletID | Wallet of service provider (marketplace). |
| ├─ ServiceProviderLicence | Licence of service provider. |
| ├─ ReceiverLicence | Licence of receiver. |
| └─ Transaction | Transaction. |
| Chosen | Frozen snapshot of the chosen model and parameters. |
| ├─ ModelType | Chosen model type. |
| └─ Parameters | Set of parameters at selection time. |
| ├─ EffectivePeriod | Validity window. |
| │ ├─ Start | Start time. |
| │ └─ End | End time. |
| ├─ Allowances[] | Frozen quota allowances. |
| │ ├─ Meter | Meter type. |
| │ ├─ Unit | Unit of measure. |
| │ ├─ Quantity | Quantity allowed. |
| │ ├─ Window | Applicable window label. |
| │ └─ Rollover | Whether unused quota rolls over. |
| ├─ Overage | Overage pricing. |
| │ ├─ Rate | Overage rate. |
| │ └─ Unit | Overage unit. |
| ├─ RateLimit | Rate limiting constraints. |
| │ ├─ MaxPerWindow | Maximum allowed per window. |
| │ ├─ Window | Window size. |
| │ └─ Burst | Burst allowance. |
| └─ PriceBreakdown | Optional breakdown of base price, discounts, and final charges. |
| Settlement | Payment proof for the SPM‑governed transaction. |
| ├─ SettlementTime | Time of settlement. |
| ├─ TargetID | Identifier of relevant Service/Asset/Licence. |
| ├─ Transaction | Transaction reference. |
| └─ Evidence[] | Optional receipts or provider references (Type, ID). |
| SPMStatus | Either “Model” or “Final”. |
| DataExchangeMetadata | Regulated/controlled exchange metadata. |
| Trace | Information about the Process producing the SPM and the time of production. |
| DescrMetadata | Free‑text descriptive metadata (≤ 2048 chars). |
Version 2.2 specifies the protocols used by a Process when it requests another Process to perform a Process Action.
Here we describe the MM-Add protocol used by a Process to request a Locate Service to place an Item at a Location.
- User sends MM-Add Process Action (PA) Request including Item, Point of View, Location, and Rights (Status=Model).
- If MM-Add is a free service, goto MM-Add.
- If MM-Add is a pay service:
- User sends MM-Add PA Request with Service Pricing Model (Status=Model) to the Locate Service of which MM-Add is an element.
- Locate sends MM-Add PA Response:
- If MM-Add PA Response includes Status=Err, goto End
- If MM-Add PA Response includes Status=Ack and Service Pricing Model including Transaction (both Status=Model), User:
- Transacts Value contained in Transaction.
- Sends MM-Add PA Request with Service Pricing Model (Status=Model) including Transaction (Status=Final) to MM-Add.
- MM-Add: Locate
- MM-Adds Item.
- Sends MM-Add PA Response (to requesting Process) including
- Rights (Status=Final) for MM-Added Item.
- Service Pricing Model (Status=Final), if MM-Add is a pay service.
- End.
As you see, the Service Pricing Model is used as the vehicle to finalise the relationship between the Requesting Process and the Locate Service.
MMM-TEC V2.2 will be presented at the online event held on on 9 April 2026 at 16 UTC. Register here to attend.
