​
Overview

An Asset Profile is a Futureverse‑specific JSON document that binds a digital asset—most commonly an NFT—to all auxiliary metadata required by Futureverse experiences. One of its primary responsibilities is to point to the UBF artifacts (blueprints and catalogs) used to parse the asset’s metadata and to render its final visual representation at runtime.

Within an Asset Profile exists the concept of Asset Variants. Variants are grouped under the ubf-variants field and represent different stylistic or technical representations of the same core asset. For example, a single asset might have a High-Fidelity variant for desktop rendering and a Low-Fidelity version for lower end devices. Additionally, a variant could represent a completely different artistic style—for instance, a LEGO-themed version of the same asset tailored for stylized or playful experiences.

The following is an example of an Asset Profile structure:

{
  "profile_version": "1.0.0",
  "ubf-variants": {
    "Default": {
      "0.2.0": {
        "render-instance": "kQ-zNQHXGSLPkU7WMNmCp",
        "render-catalog": "https://.../rcR3m91TUZ.json",
        "parsing-instance": "ZG157v4r6I4luqkrWjmYY",
        "parsing-catalog": "https://.../wuSGpuSlc4.json"
      }
    }
  }
}

NOTE: The profile_version field indicates the version of the Asset Profile schema itself. It is unrelated to the UBF standard version and exists independently to accommodate future structural changes to the profile format.

​
Versioning

Within an Asset Profile, each Variant can contain one or more Versions, with each version aligned to a specific release of the UBF Standard. This layered structure allows an asset to support multiple rendering strategies or evolve over time without requiring structural changes to the underlying asset profile. It ensures that assets remain backward compatible and can adapt to different use cases while being accessed through a single, centralized asset profile.

Each Version block under a given Variant contains the following:

  • render-instance: The ID of the blueprint used to render the asset.
  • render-catalog: The catalog URL that contains the blueprint and its required artifacts.
  • parsing-instance (optional): The ID of the blueprint used to parse metadata before rendering.
  • parsing-catalog (optional): The catalog containing the parsing blueprint and its associated resources.

This structure ensures that each version is fully self-contained, providing the necessary references for interpreters to resolve and execute the asset correctly based on the capabilities of the selected UBF version.

​
Execution Controllers & Asset Profiles

Execution Controllers are responsible for selecting the appropriate Variant and Version from an asset’s profile before triggering blueprint execution. This selection process is guided by either project-level configuration or request-level overrides:

  • Project-Level Configuration: Defines a default variant preference for the entire application (e.g., always use the Default or Mobile-Optimised variant).
  • Request-Level Overrides: Allows dynamic overrides on a per-execution basis (e.g., choosing High-Fidelity or LEGO for specific user sessions).

Once a target Variant is selected, the execution controller determines the highest available Version within that Variant that is supported by the runtime’s interpreter.

After the Variant and Version have been resolved, the controller proceeds to:

  1. Download the corresponding catalogs
  2. Resolve and execute the parsing blueprint (if present) to translate raw metadata into structured inputs.
  3. Resolve and execute the render blueprint, supplying inputs and serving artifacts on demand.