Proposal for IP infrastructure on Substrate: InvArch

[DSB-117]

Project Abstract

InvArch is a next-generation blockchain for intellectual property tokenization, development, & networking.
Under this grant, the InvArch Pallet Library would be delivered and would provide an intellectual property tokenization and utility infrastructure for the Substrate ecosystem.

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

• The application template has been copied, renamed ( InvArch.md) and updated.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.

[CLAassistant]

All committers have signed the CLA.

[mmagician]

Thanks for the application.
Could you explain what you mean by:

Instead, the platform offers many of the resources needed to take action against an individual

Am I correct in thinking that any IPT created via the platform has all its data publicly visible? It seems that your assumptions about bad actors only apply to within your system and so do all the measures to prevent them (e.g. "governed by DAOs and exists to ensure compliance and security over the network."). I only see the above making sense in a closed system (like a country with a patent office and a corresponding government), where the law can be enforced. I think your fundamental assumption about the system's security breaks down when you consider actors from the outside (i.e. anyone not using your app).

That said, your idea of using the RMRK standard for another project (outside of Kanaria) is interesting. As far as I understand though, RMRK standard doesn't need a parachain to function, and is perhaps not as customisable as a smart contract. Therefore, the deliverables 1 & 2 from Milestone 1 are confusing to me at the moment:

1. Integrate with RMRK 2.0, wrap RMRK 'Art Lego' functionality into our library. This deliverable is dependant on the development of the RMRK 2.0 Standard.

2. We will create a smart contract for minting a multi-attribute IPT and storing on Karura Parachain needed for the MVP.

Also, what exactly are you planning to store on Karura, and how? If I remember correctly, Karura doesn't support deployment of smart contracts.

[DSB-117]

Thank you for reviewing our application so quickly! We greatly appreciate your feedback and request for clarity. First and foremost, I've updated our proposal accordingly, but I also wanted to follow up here as well:

Am I correct in thinking that any IPT created via the platform has all its data publicly visible?

No, but that's because I failed to elaborate on the necessary details regarding the process of sharing an IPT's data. Hopefully, I've addressed that point better, but I would be happy to elaborate further if needed!

Therefore, the deliverables 1 & 2 from Milestone 1 are confusing to me at the moment

The RMRK standard is able to be extended by implementing a current implementation (RMRK 2.0, in our case) and wraping RMRK functionality into our own library. The founder of RMRK, Bruno Škvorc has confirmed with me that the RMRK will be available to be utilized on the Karura parachain.

Also, what exactly are you planning to store on Karura, and how? If I remember correctly, Karura doesn't support deployment of smart contracts.

The deployment of smart contracts using Ink! rust-based native smart contract platform is a confirmed future method of deployment for developers looking to deploy on Acala. The network advertises that interested developer reach out directly, and I've been fortunate to currently be in direct communications with some of the co-founders of the Acala/Karura Networks.

[mmagician]

Thanks for the update, it does indeed provide more clarity.

Some follow up questions:

1. You keep mentioning "your library". Could you explain what you mean by this, exactly?
2. I still fail to make the connection between RMRK and smart contracts. What logic exactly will be included via each, and why do you need both? Also, RMRK is supposed to function on any chain, relay- or para-, without the need for contracts.

[DSB-117]

Thank you again for the prompt replies, I really do appreciate it!

You keep mentioning "your library". Could you explain what you mean by this, exactly?

I've updated the PR to specify what I meant, as well as corrected myself. The IPT standard won't be deployed as smart contracts, instead, they'll be released as a multi-chain IPT standard, similar to how RMRK is a multi-chain NFT standard.

I still fail to make the connection between RMRK and smart contracts. What logic exactly will be included via each, and why do you need both? Also, RMRK is supposed to function on any chain, relay- or para-, without the need for contracts.

Again, my apologies. I should have clarified better. The IPT Standard will be an extension of the RMRK standard - no smart contracts are involved during Milestone 1. However, in Milestone 2, smart contracts (DEVs/DAOs) will be able to own and interact with an IPT, which will be deployed the Karura parachain using Ink!

[mmagician]

I see. Perhaps it would benefit you to make your application more generic with regard to the parachain you deploy to, especially since Karura doesn't have the functionality available (yet).

Few points I'd like to ask you to specify further.

M1:

---

We will extend the RMRK Standards

What's missing in RMRK that blocks you from using it at the moment, and how will you augment the standard exactly?

---

Implement the dApp by deploying on the Karura parachain.

You just commented that deployment of your ink! smart contract to Karura will happen in M2. Consequently, I don't understand what else you could be deploying to Karura in M1?

---

We will create a simple UI to interact with our smart contract

How so? Given that there won't be smart contracts in M1

M2:

We will create a smart contract framework for forming a DEV and implementing that framework.

It would be great to see the high level functionality that users will be able to call on the smart contracts (i.e. the contract interface)

---

Implement a very simple MVP dApp by deploying on the Karura platform and fully integrating with the Invention Arch.

Same as the comment for M1 above.

---

In general, I would like to ask you to be a bit more precise in the milestone definitions please. I'm getting an impression that the tech stack hasn't quite been figured out yet - which is OK, but perhaps in this case it might make sense to apply for just M1 first, and meanwhile let you figure out the details? Let me know what you think.

Overall, personally I'm not fully convinced of the idea behind IPTs/DEV itself, but I would still be willing to support the project for the tech of extending RMRK & linking it to smart contracts.

[DSB-117]

I apologize for the delay.

We've come to the realization that what we require is our own chain with a custom runtime and pallets. We would like to develop and deploy these pallets for the Web3 community to also utilize and build on top of, as well as so that we can integrate them into our own chain's runtime.

Overall, personally I'm not fully convinced of the idea behind IPTs/DEV itself, but I would still be willing to support the project for the tech of extending RMRK & linking it to smart contracts.

The focus of InvArch is to provide an IP blockchain infrastructure for Substrate and Substrate developers, and then to extend the utility of this infrastructure through a series of application deployments and runtime upgrades. Unfortunately, our primary focus isn't to extend the RMRK standard or link them to smart contracts. Our focus is much more significant for the Substrate ecosystem.

I understand that you're uncertain about the premises behind InvArch; however, I ask that you support us as we explore and test this new technology. If our assumptions are wrong, then it wouldn't be without effort on our end. If our assumptions are correct, then we have the potential to fundamentally decentralize and disrupt many industries and aspects of innovation that presently exist, and provide an entirely new digital asset for developers in the substrate ecosystem.

[DSB-117]

To explain the change in approach:

We realize that one day it may be possible to build an MVP of the InvArch networking platform by building on top of pre-existing projects; however, we would be heavily reliant on the development progress and focuses of those projects.

Building a custom chain using substrate and writing our own custom pallets doesn't just help allow us to design an optimal runtime for our chain's specific use cases, it allows us to more easily integrate and expand these technologies throughout the Substrate ecosystem.

[mmagician]

Sounds like a plan. Good luck with the project!

[DSB-117]

Thank you so much for your review! I promise that given this opportunity, we will dedicate our all to delivering on our milestones and helping to bolster the Substrate ecosystem!

I noticed that the PR says 5 approving reviews are required instead of the typical requirement of 3 for level 2 funding and believe I realized why. I've updated our proposal to comply with the terms and conditions under the grant for first-time applicants and would appreciate your review (again) when you get the chance.

Again, thank you so much for your time @mmagician!

[mmagician]

This is just a github feature - once it reaches 3 approvals it will be merged.

[semuelle]

Hi @Invarchitect, couple of questions:

• What does Pallet_dev provide that Pallet_dao doesn't? The description of a DEV sounds like a DAO owning one or more IPSets to me.
• How are files attached to a token?
• recieve rewards for when their work is viewed by other users -- I couldn't find this aspect described anywhere, could you expand what that would look like?
• Could you describe where you see InvArch compared to the current, legal handling of IP and rights management? Is it expected to establish copyright, legally?

[DSB-117]

Hi @semuelle! Thank you for taking the time to look over our proposal. I've updated our proposal to directly address your questions, but will overview briefly below:

What does Pallet_dev provide that Pallet_dao doesn't? The description of a DEV sounds like a DAO owning one or more IPSets to me.

Pallet_dev serves to initialize and structure the required/requested roles a project needs and their IP Ownership allocations, sets its milestones/deliverables, copyright terms, if any, and decides its application process. A DEV can also be imagined as a digital representation of a real-world development project.

Pallet_dao will solely be focused on proving the governance logic in our runtime. We would prefer to keep these separate, as we would like to explore expanding the Pallet_dao to include multi-layer governance capabilities in the future.

How are files attached to a token?

IPFS or Interplanetary File System allows data and IP contents to be securely stored off-chain and given a CID, or content identifier, that serves as a unique hash and is used to mint IP Tokens. The InvArch protocol will include the ipfs_api crate to help achiave this.

"receive rewards for when their work is viewed by other users" -- I couldn't find this aspect described anywhere, could you expand what that would look like?

That's something we wish to explore in the future, possibly under a separate grant. I didn't intend to have that there when I committed. It's been removed.

Could you describe where you see InvArch compared to the current, legal handling of IP and rights management? Is it expected to establish copyright, legally?

It can only establish "legal" copyright where NFTs are recognized as such; however, it serves as a very powerful tool in those instances. Regarding registering copyright, we would like to explore streamlining this process between users and centralized entities (legal institutions) in the future. Our focus now is developing the underlying architecture required to build these features.

[semuelle]

Thanks for the quick reply.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[alxs]

@Invarchitect any updates on the second milestone?

[alxs]

@Invarchitect @SHA888 do you still intend to finish the grant? If you can't submit the second milestone within the next 2-3 weeks, could you please submit an amendment to adjust its duration?

[alxs]

@Invarchitect @SHA888 note that if we don't hear from you within the next two weeks, we'll assume you're no longer interested and terminate the grant.

[DSB-117]

@alxs I'm really sorry for the delay. We've had a lot of needed improvements & changes take place around the project over the course of the last several months, some of them being expansive. We're not looking to implement the DEV protocol; rather, focusing on 1: IP file composability, pegged assets & sub-assets, licensing, & cross-chain authentication (XCA).

I believe it's best if we submit an amendment and just focus on providing a more composable IP Pallet package, we'll be providing the latter tech, but through milestones in a builders program. I will have the amendment ready by this Wednesday if that's acceptable?

[alxs]

@Invarchitect sounds good! We'll gladly review the amendment.

[alxs]

@Invarchitect friendly reminder.

[semuelle]

@Invarchitect @SHA888 If we don't hear back from you or receive an amendment until next week, we'll assume you are no longer interested in pursuing it and will cancel the grant. You are free to reapply anytime.

[DSB-117]

@semuelle, we're finished development on the work under the grant (considering our changes, as well).

I apologize for not pushing an amendment sooner. I promise to have updated by the weekend & ready for your review coming into next week. We're excited for your review!

[semuelle]

Thanks for the update, @Invarchitect.

[DSB-117]

Hey @semuelle, I just submitted PR #950 as mentioned above.
If I filled out anything incorrectly or against the standard procedures, please let me know & I'll get on top of it ASAP.

[alxs]

@XCAstronaut a reminder to submit the next milestone, seeing as the amendment was accepted 2 weeks ago and assuming your intention was to submit immediately.

[DSB-117]

@alxs, we are internally reviewing the code for the INV4-Git middleware now to make sure everything is in perfect order.

I will be traveling in about 12 hours, but I should hopefully be submitting our completed proposal within the next 24 hours.

[DSB-117]

@alxs, I wanted to follow-up & be transparent. Everything in the grant is complete, including the INV4-GIT middleware; however, after reviewing the code from our team, our Head of Tech. would like to iterate over a few things & make some improvements.

We can submit now if needed, but otherwise would ask if way may submit this Monday. Regardless, INV4-GIT is a key product for InvArch & our future GitArch app, and we will be maintaining & continuously improving it.

To be specific to now, we've just finished incorporating RMRK into INV4, which calls for some slight upgrades to INV4-GIT.

[alxs]

Hey @XCAstronaut, thanks for the update. Feel free to submit when you're ready. It's great to hear you want to deliver a mature product.