Abstract

This specification defines the structure of an asset in the ENVITED-X Data Space and outlines the process for uploading assets to ensure compliance, security, and interoperability. It leverages existing specifications, such as the Gaia-X Trust Framework, the ENVITED-X Ontologies, and implements privacy layers, validation, and metadata mapping aligned with ERC-721 token metadata following the OpenSea Metadata Standards.

Motivation

Standardizing the definition and upload process for digital assets SimulationAssets in the ENVITED-X Data Space ensures:

• Interoperability with existing Gaia-X data spaces.
• Security through CID-based identification and metadata validation.
• Scalability for integrating diverse asset types.

This EVES addresses the need for clear guidelines to onboard assets and synchronize data with ENVITED-X systems.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1. Digital Asset Definition

The envited-x:SimulationAsset defines a digital asset within the domain of simulation including the core simulation data and all necessary files for describing, evaluating, and visualizing the dataset. All simulation assets MUST be derived from a common envited-x ontology defined in the ASCS Ontology Management Base. A data space portal SHALL display the currently supported version of the ontologies such as: https://w3id.org/ascs-ev/envited-x/envited-x/v3/. Each simulation asset SHALL be compliant with the Gaia-X Ontology and SHACL shapes 2210. The gx turtle SHACL shapes are derived from the Gaia-X Trust Framework Schema and the respective application/ld+json Gaia-X Trust Framework Shapes. A GaiaX Compliant Claims Example MAY be generated using the GaiaX 4 PLC-AAD Claim Compliance Provider.

The example implementation in the 📁 example/ folder is based on release v0.2.3 of the ASCS HD-Map Asset Example.

Asset examples can be found in the following repositories:

• HD-Map Asset Example
• Environment Asset Example
• Scenario Asset Example
• OSI-Trace Asset Example

1a. Asset Lifecycle Overview

An envited-x:SimulationAsset progresses through three stages from creation to publication. All stages use the same envited-x and manifest ontology vocabulary to ensure consistency and machine-readability throughout.

┌─────────────────────┐      ┌──────────────────────────┐      ┌─────────────────────────────┐
│  Stage 1:           │      │  Stage 2:                │      │  Stage 3:                   │
│  PREPARATION        │      │  PACKAGING               │      │  PUBLICATION                │
│                     │      │                          │      │                             │
│  input_manifest.json│─────▶│  asset.zip containing:   │─────▶│  envited-x_manifest.json    │
│  (user-provided)    │      │  manifest_reference.json │      │  erc721_token_metadata.json │
│                     │ asset│  + all asset files       │portal│                             │
│                     │ tools│                          │upload│                             │
└─────────────────────┘      └──────────────────────────┘      └─────────────────────────────┘

• Stage 1 — Preparation: The user describes their input files in an input_manifest.json using the envited-x vocabulary. This partial manifest specifies file paths, categories, access roles, and MIME types.
• Stage 2 — Packaging: Asset creation tooling (such as the ENVITED-X Simulation Asset Tools) processes the input manifest, computes CIDs and file sizes, generates additional artifacts, and packages everything into an asset.zip with a complete manifest_reference.json.
• Stage 3 — Publication: The ENVITED-X portal uploads the asset, replaces local file paths with IPFS/HTTPS URLs, generates the final envited-x_manifest.json, and creates chain-specific token metadata files for minting.

Example Files

The 📁 example/ folder contains files from each stage of this pipeline:

Note: The example asset.zip is from hd-map-asset-example v0.2.3 and uses earlier ontology versions internally (manifest/v4, envited-x/v2). The standalone example files reflect the current ontology versions (manifest/v5, envited-x/v3). A future release of the HD-Map Asset Example will align both.

1b. Asset Preparation

Before uploading, an asset MUST be organized into a well-defined folder structure and described by an input manifest. Tooling such as the ENVITED-X Simulation Asset Tools MAY automate the creation of a conformant asset.zip from user-provided input files and an input_manifest.json.

Folder Structure

Every asset.zip MUST contain the following top-level folders mapped to envited-x artifact categories:

Note: The envited-x categories and access roles are formally defined in the ENVITED-X Ontology which extends the generic Manifest Ontology. The envited-x:ExtendedLinkShape constrains the allowed values for both manifest:hasCategory and manifest:hasAccessRole.

Input Manifest (input_manifest.json) — Stage 1: Preparation

An input_manifest.json is a partial envited-x:Manifest in JSON-LD that describes the user-provided input files before the asset creation pipeline processes them (see §1a). It uses the same envited-x and manifest vocabulary as the final manifest_reference.json but omits computed fields (cid, fileSize, timestamp, hasDimensions, filename) and structural entries (hasManifestReference, iri) that are generated by the pipeline.

Each entry (a manifest:Link) MUST specify:

• manifest:hasCategory — one of the categories defined in the envited-x ontology
• manifest:hasAccessRole — one of the access roles defined in the envited-x ontology
• manifest:hasFileMetadata — a manifest:FileMetadata node with at minimum:
  • manifest:filePath (xsd:anyURI) — local file path or remote URL
  • manifest:mimeType (xsd:string) — MIME type of the file

Two-Stage Validation

Asset creation tooling SHOULD implement a two-stage validation approach (see also §4 Step 1 for portal-side validation):

1. Input validation (fail fast): Each manifest:Link in the input_manifest.json SHOULD be validated against manifest:LinkShape and envited-x:ExtendedLinkShape before the pipeline runs. This catches invalid categories, missing access roles, or malformed file metadata early.
2. Output validation (completeness): The completed manifest_reference.json MUST be validated against the full envited-x:ManifestShape, which requires at least one artifact per core category (isSimulationData, isDocumentation, isMetadata, isMedia).

Example input_manifest.json — Stage 1: Preparation

See 📁 example/input_manifest.json for a complete example.

{
  "@context": ["https://w3id.org/ascs-ev/envited-x/envited-x/v3/", "https://w3id.org/ascs-ev/envited-x/manifest/v5/", { "gx": "https://w3id.org/gaia-x/development#", "xsd": "http://www.w3.org/2001/XMLSchema#" }],
  "@id": "did:web:registry.gaia-x.eu:HdMap:example",
  "@type": "envited-x:Manifest",
  "hasArtifacts": [
    {
      "@type": "manifest:Link",
      "hasAccessRole": { "@type": "manifest:AccessRole", "@id": "envited-x:isOwner" },
      "hasCategory": { "@type": "manifest:Category", "@id": "envited-x:isSimulationData" },
      "hasFileMetadata": {
        "@type": "manifest:FileMetadata",
        "filePath": "my_map.xodr",
        "mimeType": "application/x-xodr"
      }
    },
    {
      "@type": "manifest:Link",
      "hasAccessRole": { "@type": "manifest:AccessRole", "@id": "envited-x:isPublic" },
      "hasCategory": { "@type": "manifest:Category", "@id": "envited-x:isMedia" },
      "hasFileMetadata": {
        "@type": "manifest:FileMetadata",
        "filePath": "impression-01.png",
        "mimeType": "image/png"
      }
    }
  ],
  "hasLicense": {
    "@type": "manifest:Link",
    "hasAccessRole": { "@type": "manifest:AccessRole", "@id": "envited-x:isPublic" },
    "hasCategory": { "@type": "manifest:Category", "@id": "envited-x:isLicense" },
    "hasFileMetadata": {
      "@type": "manifest:FileMetadata",
      "filePath": "https://www.mozilla.org/en-US/MPL/2.0/",
      "mimeType": "text/html"
    }
  }
}

The asset creation pipeline (Stage 2: Packaging) enriches this into a full manifest_reference.json by:

1. Computing manifest:cid (IPFS CIDv1) for each file
2. Computing manifest:fileSize and manifest:timestamp
3. Extracting manifest:hasDimensions for images
4. Adding generated artifacts (documentation, metadata, validation reports)
5. Adding the self-referencing manifest:hasManifestReference entry
6. Adding manifest:iri to the license link (required by envited-x:LicenseLinkReferenceShape)

2. Pinata IPFS and CID Management

It is RECOMMENDED to use IPFS within the ENVITED-X Data Space for making public data available. IPFS is a peer-to-peer content delivery network built around the innovation of content addressing: store, retrieve, and locate data based on the fingerprint of its actual content rather than its name or location.

CID v1

Artifacts uploaded to IPFS, for example using services like Pinata MUST use the content identifier version CID v1.
In Pinata this is achievable through the API using the pinataOptions parameter, as outlined in the documentation.

File Naming

Uploaded file names MUST exclude extensions (for example, use file instead of file.json) to avoid issues such as double extensions during downloads (for example, file.json.json).

3. Privacy Layer

The ENVITED-X Data Space implements a three-tiered privacy model:

4. Asset Validation and Upload Process

The following process is implemented in the ENVITED-X Data Space portal developed by the Automotive Solution Center for Simulation e.V.

Step 1: Client-Side Pre-Validation

• Verify that an input_manifest.json was used during asset preparation (see §1b and Two-Stage Validation):
  1. Each manifest:Link in the input SHOULD have been validated against manifest:LinkShape and envited-x:ExtendedLinkShape as described in §1b.
• Drag and drop asset.zip into the upload field.
• Validate the manifest_reference.json:
  1. Ensure JSON structure matches the manifest SHACL constraints.
  2. Verify all referenced files exist locally or remotely as specified.
  3. Locate the domainMetadata.json file.
• Validate the domainMetadata.json:
  1. Extract SHACL constraints from the domainMetadata.json context,
  2. Validate JSON structure against domain-specific SHACLs,
  3. Check if the @id is unique within the ENVITED-X Data Space,
  4. If the asset @id is already existing the validator SHALL throw an error.
• Validate if items in hasReferencedArtifacts are available:
  1. Check if @id of asset is known in the database,
  2. OPTIONALLY check if filePath resolves if the access role is isPublic,
  3. It is RECOMMENDED to warn the user if references do not exist,
  4. It is strongly RECOMMENDED to add the CID as a user to the Manifest metadata.

Step 2: Upload Asset to ENVITED-X Data Space

• Trigger the upload process by clicking the "Upload" button.
• Calculate the CID of asset.zip.
• Rename asset.zip to CID.zip and store at https://assets.envited-x.net/Asset-CID.
• Store isRegistered metadata at https://metadata.envited-x.net/Asset-CID.
• Store isPublic metadata at https://ipfs.envited-x.net/Asset-CID/Data-CID.
• Calculate CIDs for all isPublic data.
• Create envited-x_manifest.json (Stage 3: Publication) by replacing relative paths in manifest_reference.json with IPFS/envited-x.net URLs.
• Replace the paths of items in hasReferencedArtifacts to the correct filePaths.
• Replace @id from manifest_reference.json with generated database UUID in envited-x_manifest.json. This also applies for referenced artifacts.
• Create erc721_token_metadata.json following the OpenSea Metadata Standards and map the metadata fields as defined in §6 Token Metadata.

Step 3: Preview Data

• Visualization and preview mechanisms for uploaded data are portal-specific and not specified in this revision.
• If a user triggers the "delete asset" button then all data stored in Step 2) is deleted.

Step 4: Mint Token

• It is RECOMMENDED to use signed CIDs for the upload to IPFS according to EIP-712.
• Upload isPublic information and envited-x_manifest.json to IPFS.
• It is RECOMMENDED to verify that CIDs from the IPFS service or software returns the same CIDs as the pre-calculation.
• Upload erc721_token_metadata.json to IPFS.
• Mint an ERC-721 token where tokenURI() resolves to the ERC-721 metadata JSON on IPFS. The contract SHOULD implement ERC-5192 for soulbound (non-transferable) tokens if applicable. The contract SHOULD emit ERC-4906 MetadataUpdate events when metadata changes.
• The mint transaction MAY be submitted by a relayer on behalf of the user; signed authorization evidence links the registration to the minting organization's identity (see §6 Token Metadata).
• The wallet/SDK will provide feedback if a token was minted successfully.

Step 5: Listener and Database Synchronization

• Use a listener to detect mint events and synchronize data with the ENVITED-X Data Space portal database.
• A data space like the ENVITED-X Data Space MUST check if the asset was uploaded through its respective portal:
  • UUID from step 2) has an entry in the database.
  • Confirm that contract + CID and minter of the erc721_token_metadata.json are the same as in the database.
  • Confirm that the entries UUID and @id of the asset are unique.
  • OPTIONALLY check if the EIP-712 signature of the token metadata file matches the user who initiated the mint (SHALL only be known to the respective portal).
• If the asset is not yet in DB OPTIONALLY mark it as foreign asset and add the publisher information to the DB.
• It is RECOMMENDED to verify the asset in reverse order as in step 1).
• Only public information of assets can be verified if uploaded through another portal than ENVITED-X data space.

5. Database Synchronization

@id and CID as the Primary Identifier

• The CID of the uploaded asset.zip serves as the unique identifier detecting identical datasets across all systems.
• In addition the unique identifier @id of the envited-x:SimulationAsset in the domainMetadata.json SHALL be used for identification of the digital assets.
• The CIDs MAY be signed by the user according to EIP-712.
• A UUID MUST be generated for the envited-x_manifest.json pre-mint to link the asset with the ENVITED-X database securely.
• The DID of the member associated with the user minting the asset MUST be known.
• DID of the user minting the asset SHALL be stored pre-mint in the database.

Pre-Mint Information

If additional non-public information needs to be stored in the database before minting, the CID can associate this data with the minted asset.

Synchronization and Security

EVES-007 defines the ENVITED-X Blockchain Identifier URN Schema. The synchronization between the smart contract as in the Marketplace Contract Reference Implementation and the ENVITED-X database relies on:

1. The contract identifier using the EVES-007 URN schema, for example (Etherlink L2): urn:blockchain:eip155:42793:contract:0x646B92C8f21e55DF67E766047E4bD7bEdF8DfA14
2. Search CID of the erc721_token_metadata.json and the complete asset.zip in database.
3. Compare if signature on CID is a user belonging to the member and if member is owner of token.
4. Check: Uniqueness of CID in database.

6. Token Metadata

This section defines how EVES-003 asset metadata (derived from the ENVITED-X manifest and domain metadata) is mapped to ERC-721 token metadata.

Token metadata is registered on-chain through an evidence-based listing registry: the minted ERC-721 token records the minting organization's DID, a hash of the canonical metadata document, and the metadata URI. The registration is accompanied by signed authorization evidence (for example, a key-binding JWT produced by an SSI wallet as defined in EVES-008) that links the mint to the organization's identity. The exact registration flow and the precise structure of the registered document follow the reference implementation and may be refined in a future revision of this EVES; the field mappings below are normative for the content of the ERC-721 metadata.

The minter MUST be a simpulseid:OrganizationParticipant (LegalEntity) identified by their did:ethr DID as defined in EVES-008. The did:ethr identifier is anchored on Base (ERC-1056) and serves as the organizational identity regardless of the chain the token is minted on. The natural person performing the mint is linked to the organization through the memberOf credential property. Some of the information needs to be extracted from the gx:LegalParticipant via the SimpulseID ParticipantCredential.

The minter field is part of the off-chain metadata JSON and therefore states the organization's DID as a claim: a different Ethereum address (for example, a gas relayer) may submit the mint transaction, so the transaction sender carries no trust semantics. The smart contract does not verify this claim at mint time. Instead, consuming systems verify the claimed minter DID against an ecosystem root of trust — such as the key material anchored in the organization's did:ethr DID document or credentials issued by a trust anchor — when reading the token. Where and when in the asset lifecycle this verification takes place remains open in this revision (see Future Improvements).

ERC-721 Metadata (EVM)

ERC-721 token metadata follows the OpenSea Metadata Standards which extend the minimal ERC-721 tokenURI() JSON schema with additional fields. Attributes not in the table are static and the same for every mint as in the 📁 example/erc721_token_metadata.json (Stage 3: Publication).

Attributes mapping note: Ecosystem classification and ontology conformance are expressed in the OpenSea-style "attributes" array using "trait_type"/"value" objects.

Every mint MUST include the following canonical static attributes:

Each ontology attribute uses the full ontology IRI as trait_type and the release URL as value (for example, {"trait_type": "https://w3id.org/ascs-ev/envited-x/hdmap/v6/", "value": "https://github.com/ASCS-eV/ontology-management-base/releases/tag/v0.1.6"}). Using the full ontology IRI as trait_type ensures each attribute is unique and machine-parseable.

Ontology attributes: The attributes section SHOULD include all ontologies that the asset instance conforms to. For an HD-Map asset, the following ontology attributes are RECOMMENDED:

• Domain ontology (for example, hdmap/v6): identifies the simulation asset type
• Ecosystem ontology (envited-x/v3): identifies the asset as part of the ENVITED-X Data Space
• Gaia-X ontology (gx): signals conformance with the Gaia-X Trust Framework for data space interoperability
• Georeference ontology (georeference/v5): included when the asset contains geospatial reference data (OPTIONAL per the HD-Map Ontology SHACL shapes)

The value for each ontology attribute SHOULD be the release URL of the ASCS Ontology Management Base version used, except for gx which references the Gaia-X Policy Rules Compliance Document.

Note: Fields marked as "(EVES extension)" are not part of the base ERC-721 or OpenSea standard but are defined by EVES-003 for interoperability with the ENVITED-X Data Space. Marketplaces will display name, description, image, animation_url, external_url, and attributes natively; EVES extension fields are consumed by the ENVITED-X portal.

ERC-7572 Contract-Level Metadata (EVM)

For EVM-based deployments, the marketplace contract SHOULD implement ERC-7572 by exposing a contractURI() function that returns a URI to a JSON document describing the contract/collection.

The contractURI() response SHOULD include at minimum:

• name: the collection name (for example, "ENVITED-X Simulation Assets")
• description: a description of the collection
• image: a collection image/logo URI
• external_link: URL to the ENVITED-X Data Space portal

The contract SHOULD emit a ContractURIUpdated() event as defined in ERC-7572 when the contract-level metadata is changed.

Custom SPDX license identifier

• Custom license in a LICENSE file in the asset.zip root folder: "LicenseRef-Custom-Commercial-Agreement"
• Custom license in a smart contract as json-ld ODRL policy: "LicenseRef-Policy-Smart-Contract"

Backwards Compatibility

This specification introduces new processes for asset uploads. Earlier revisions of this EVES defined a Tezos/TZIP-21 token metadata path; the ENVITED-X Data Space no longer uses Tezos, and that path has been removed. As this specification and all its deployments are still drafts, no backwards compatibility with previously minted Tezos assets is maintained.

Future Improvements

• The compatibility with the current release of the Gaia-X Policy Rules Compliance Document (Release 24.11) is to be implemented in a future update of this EVES.
• The point in the asset lifecycle at which minted tokens and the claimed minter identity are verified against an ecosystem root of trust, and the components responsible for this verification, will be specified in a future revision of this EVES.
• On-chain verification of the minting organization's key material (for example, through P-256 signature verification via RIP-7212) is a possible future extension.

References

• ASCS Ontology Management Base
• Gaia-X Ontology and SHACL shapes
• Gaia-X Trust Framework Schema
• Gaia-X Trust Framework Shapes
• GaiaX Compliant Claims Example
• GaiaX Claim Compliance Provider
• ASCS HD-Map Asset Example
• IPFS
• Pinata
• Pinata API Documentation
• CID v1 Content Addressing
• ENVITED-X Data Space Portal
• EIP-712
• SPDX License List
• RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels
• Gaia-X Policy Rules Compliance Document (Release 24.11)
• Marketplace Contract Reference Implementation
• ENVITED-X Simulation Asset Tools
• ENVITED-X Ontology
• Manifest Ontology
• OpenSea Metadata Standards
• ERC-4906: EIP-721 Metadata Update Extension
• ERC-5192: Minimal Soulbound NFTs
• ERC-721: Non-Fungible Token Standard
• ERC-7572: Contract-Level Metadata via contractURI()
• EVES-008: ENVITED-X Identity and Credential Framework
• RFC 1766: Tags for the Identification of Languages
• HD-Map Ontology
• EVES-007: ENVITED-X Blockchain Identifier URN Schema
• RIP-7212: Precompile for secp256r1 Curve Support