Metadata storage for Orignal Works assets

[revelator-labs]

Stored data on the protocol includes two types of files:

• metadata - information about an asset* in the form of IPFS backup and "latest state" subgraph, provided by a valid OWEN user and includes the ISCC hashes of the asset's related release(s) cover art, and the ISCC hash of the audio (if provided by OWEN).
• media files - in case the cover art image is provided it will be shrunk and stored on IPFS alongside the metadata stored on IPFS. Audio files are never stored beyond the initial inclusion in a blob (if included by OWEN) and the validator will always delete them after generating the ISCC code

*for clarifications: "Assets" registered on the OW protocol are either "Recordings" (unique ISRC per asset) or "Works" (unique ISWC per asset). Although the registry will unify those records grouped by "Releases" with related "cover art" and UPC codes, the assets that are being monetized by the protocol will always relate to a single unique identifier: ISRC or ISWC.

Below are the storage requirements for Original Works stakeholders

1. Rihghtsholders - They do not need to be bothered and would expect their asset to be available as long as their Royalty Admin is monetizing their IP and ensuring they get paid; At the same time, any rightsholder (or generally any person/contract) who wishes to sync the data on their IPFS node should be able to do it and (if it's not a simple permissionless action via IPFS clients like pinata) the protocol should enable a simple gateway to pin that data to one's node...
2. Royalty Admins - They are the ones who end up paying for this and will decide to charge rights holders for it. Payment will always be in $OWN to the Validator
3. Validators - They take care of - they should be able to extend storage of either data or images per request from OWEN users by charging an additional fee in $OWN and settling the long-term storage costs.

In order to provide basic guarantee of data availability the requirements for core protocol developers are as follows:

• Generate subgraph index upon registration or any update of the asset
• Provide IPFS storage for x months based - "Basic Storage"
• OWEN adds a fee and calls special method to extend the storage by x months (q: do validators compete on fees to include storage or is there a protocol cost based on current Storacha costs)?

Implementation method(s):

1. Phase I: OW foundation manages a single Storacha account and creates a space per OWEN client user - OW covees long-term storage.
2. Phase II: include $OWN settlement for storage between OWEN and Validators
3. Allow OWEN customers to configure their own IPFS/Storacha account (?)

[revelator-labs]

Probably better to focus on "OWN foundation" will offer additional storage as a service from a technical complexity and economical standpoint - this means a single Storacha account for all OWN records.

[denciu]

WIP

Stored data on the protocol includes two types of files:

• metadata - information about an asset* in the form of IPFS backup and "latest state" subgraph, provided by a valid OWEN user and includes the ISCC hashes of the asset's related release(s) cover art, and the ISCC hash of the audio (if provided by OWEN).

In other words metadata is what we index by the subgraph.

• media files - in case the cover art image is provided it will be shrunk and stored on IPFS alongside the metadata stored on IPFS. Audio files are never stored beyond the initial inclusion in a blob (if included by OWEN) and the validator will always delete them after generating the ISCC code

To clarify - Owen will generate ISCC, Validator shouldn't be involved in it. Also, by inclusion audio to the blob we mean IPFS CID, not a file itself.

*for clarifications: "Assets" registered on the OW protocol are either "Recordings" (unique ISRC per asset) or "Works" (unique ISWC per asset). Although the registry will unify those records grouped by "Releases" with related "cover art" and UPC codes, the assets that are being monetized by the protocol will always relate to a single unique identifier: ISRC or ISWC.

Below are the storage requirements for Original Works stakeholders

1. Rihghtsholders - They do not need to be bothered and would expect their asset to be available as long as their Royalty Admin is monetizing their IP and ensuring they get paid; At the same time, any rightsholder (or generally any person/contract) who wishes to sync the data on their IPFS node should be able to do it and (if it's not a simple permissionless action via IPFS clients like pinata) the protocol should enable a simple gateway to pin that data to one's node...

If we talk in context of Storacha then unfortunately it's not as easy as syncing entire nodes (because of how Filecoin works). What's certain, we are able to list all assets of the Rightsholder (metadata + media stored on Storacha by us) and make them available for download straight from the Storacha (from IPFS to be precise). At this point we don't have any mechanism allowing anyone to update links to assets IPFS but we could make it possible by sending ERN with some kind of annotation that links in the message are guaranteed by the Royalty Admin to be working and then we won't bother with uploading them.

2. Royalty Admins - They are the ones who end up paying for this and will decide to charge rights holders for it. Payment will always be in $OWN to the Validator

In curent model (single Storacha account) we pay for Storacha space in fiat.

3. Validators - They take care of - they should be able to extend storage of either data or images per request from OWEN users by charging an additional fee in $OWN and settling the long-term storage costs.

In order to provide basic guarantee of data availability the requirements for core protocol developers are as follows:

• Generate subgraph index upon registration or any update of the asset
• Provide IPFS storage for x months based - "Basic Storage"
• OWEN adds a fee and calls special method to extend the storage by x months (q: do validators compete on fees to include storage or is there a protocol cost based on current Storacha costs)?

Implementation method(s):

1. Phase I: OW foundation manages a single Storacha account and creates a space per OWEN client user - OW covees long-term storage.
2. Phase II: include $OWN settlement for storage between OWEN and Validators
3. Allow OWEN customers to configure their own IPFS/Storacha account (?)

[revelator-labs]

Additional components for long-term storage indexing; Rercord the following details on subgraph per batch:

1. metadata coming from the OWEN client: OWEN version, Operator (Royalty Admin) 0x address
2. metadata coming from the Validator client: Validator Client version, Operator 0x address
3. List of ERN message IDs
4. List of verified ISRCs/ISWCs registered
5. List of reported ISRCs/ISWCs

[denciu]

Metadata storage status for OW as of April 30, 2025

While sending an ERN to the Protocol via Owen, the Operator (Royalty Admin) uploads media files (images, and in the future, audio) to IPFS via a client-managed Pinata account. The Operator must provide a Pinata token as an environment variable to Owen. The ERN is modified to include CIDs of the media assets instead of URLs.

The Validator picks up the blob, stores it locally, and for each ERN, downloads the media assets from IPFS, stores the parsed ERNs in JSON format, and generates metadata. These files — assets, JSONs, metadata, and the blob — are then stored in Storacha, which is managed by OW.

For a few reasons, this backup is handled by the Validator (using the OW Storacha account), not by Owen:

• Enforcing Operators to guarantee data availability for backups is cumbersome and difficult to implement.
• The Validator may reject the blob, and any files uploaded by Owen would become redundant — resulting in wasted resources for the Operator.
• The Validator is in a position to prove that the data on IPFS is legitimate.

We chose Storacha as the storage provider because blob backups are a long-term audit requirement (so anyone can re-execute our circuit to verify its correctness). This is a core feature of the Protocol, and the most optimal solution is to use a single Storacha account managed by OW, delegating uploads to Validators.

---

With the above context in mind:

1. Rihghtsholders - They do not need to be bothered and would expect their asset to be available as long as their Royalty Admin is monetizing their IP and ensuring they get paid; At the same time, any rightsholder (or generally any person/contract) who wishes to sync the data on their IPFS node should be able to do it and (if it's not a simple permissionless action via IPFS clients like pinata) the protocol should enable a simple gateway to pin that data to one's node...

There won't be any additional actors involved in storage decentralization. Since we cannot enforce data availability on Rightsholders, the responsibility for storage is delegated to Validators, who upload files to the OW Storacha account (which is itself decentralized behind the scenes). If someone wants to back up the files of a Release, they’re free to download them from Storacha, but such backups do not influence the Protocol.

2. Royalty Admins - They are the ones who end up paying for this and will decide to charge rights holders for it. Payment will always be in $OWN to the Validator

3. Validators - They take care of - they should be able to extend storage of either data or images per request from OWEN users by charging an additional fee in $OWN and settling the long-term storage costs.
   In order to provide basic guarantee of data availability the requirements for core protocol developers are as follows:

Generate subgraph index upon registration or any update of the asset
Provide IPFS storage for x months based - "Basic Storage"
OWEN adds a fee and calls special method to extend the storage by x months (q: do validators compete on fees to include storage or is there a protocol cost based on current Storacha costs)?
Implementation method(s):

Phase I: OW foundation manages a single Storacha account and creates a space per OWEN client user - OW covees long-term storage.
Phase II: include $OWN settlement for storage between OWEN and Validators
Allow OWEN customers to configure their own IPFS/Storacha account (?)

Royalty Admins (Operators) will cover initial storage costs by including a fee in the blob transaction. This fee will cover storage for a defined period (x months); after that, the Royalty Admin must renew it. In this process, the Validator acts merely as a messenger between the Royalty Admin and the OW Storacha account. There is no added value in involving the Validator in the renewal process, so we should look for a better solution.

---

Optimization opportunity

Given that Owen uploads media files to IPFS using Pinata solely so the Validator can later reupload them, there is room for improvement. Since the files uploaded by Owen are only needed temporarily, Owen could instead upload them directly to the OW Storacha account. After the Validator reuploads the files to IPFS, the temporary Storacha files can be cleared.

This would eliminate the need for Royalty Admins to manage a Pinata account, reducing their operational overhead and simplifying Owen client setup.

---

Topics for discussion

• What should the storage fee be, and for how long should it cover storage? (Define the economic model.)
• What happens if the Royalty Admin fails to prolong storage? What should happen to the backups and media files, and how should that affect the Protocol?
• How should Royalty Admins pay to prolong storage? Off-chain billing? Smart contract interaction?
• Should Royalty Admins be able to manage the files they upload? Should they be able to monitor which files they’re paying for?
  • Should we create a dedicated backend/frontend for storage management?
  • Should we send reminders about storage expiration?

---

Additional consideration

How should we organize files uploaded to Storacha?
Currently, we use a single space per chain, but it might be more beneficial to switch to a separate space per Royalty Admin. This is something we could consult with the Storacha team to get their input on.