Dark Light

Vision For An IP Ownership, Utility, & Cross-Consensus Authentication Protocol For Web 3.0

DRAFT 0 〡 Dakota Barnett 〡 January 21st, 2022

ABSTRACT: This paper introduces the conception for a protocol that utilizes blockchain technology to allow individuals to tokenize and store their intellectual property (IP) as intellectual property files (IPFs), combine IPFs into collections called IP Sets, and utilize programmable IP Tokens pegged to an IP Set. This design allows these new tokens to leverage social, business, financial, and governance transaction utility. This protocol will serve as a foundation for a new global economy of decentralized ownership and management that will help streamline innovation and opportunity. The pallets responsible for IP tokenization will be modular; however, slightly different by design than the pallets responsible for IP tokenization found natively on InvArch. InvArch will serve as the center point of IP tokenization and authentication. Utilizing lateral cross-consensus messaging (XCM), a technological breakthrough made possible by the Polkadot relay chain, IP Files minted on other chains throughout the Paraverse will have their data sent from their native chains and through the Polkadot relay, where InvArch and cross-references will receive them for plagiarism. This technology will provide a mechanism for instantly validating content and flagging duplicated files. Through the achievement of the InvArch parachain, the InvArch SDK, and Cross-Chain Authentication, InvArch will provide a permanent and upgradeable protocol for IP management, utility, and authentication.

History

1. Relevant Blockchain Technology & Intellectual Property Background Information - There are a few yet important technologies & topics to have some degree of familiarity with in order to fully understand the information laid out in this paper. They include blockchain technology precursors, which have led to the feasibility to develop the InvArch, and the realm of intellectual property, which has led to the issues supporting the protocol’s development.

1.1. Bitcoin, Ethereum & Polkadot
- Blockchain has evolved swiftly since Satoshi Nakamoto first published the Bitcoin whitepaper in 2008 and showcased the technology for “A Peer-to-Peer Electronic Cash System” and soon after created the world’s first cryptocurrency. In 2013 the Ethereum whitepaper was published by Vitalik Buterin which redefined the blockchain industry by introducing “A Next-Generation Smart Contract and Decentralized Application Platform,” that realized Solidity & the Ethereum Virtual Machine (EVM), decentralized autonomous organizations (DAOs), decentralized finance (DeFi), & non-fungible tokens (NFTs). Dr. Gavin Wood, Co-founder & yellow paper author of Ethereum, realized scalability & interoperability issues plaguing the blockchain ecosystem and argued his “Vision For A Heterogeneous Multi-Chain Framework” to solve them when he published the Polkadot whitepaper in 2016.
- 1.1.1. Bitcoin & Decentralized Public Ledgers
  - Bitcoin was the world’s first cryptocurrency & first large-scale project built using blockchain technology to experience international adoption & used the technology to establish a distributed & open-source public ledger. The ledger was available for all to see, with information recorded in the ledger verified through a proof-of-work (PoW) consensus mechanism that records transactions by hashing them into an ongoing chain composed of immutable & hash-based blocks of data (bitcoin.org/bitcoin.pdf). The intention of the Bitcoin network was to establish a truly peer-to-peer currency system where payments could be sent directly from one party to another without requiring any 3rd-party or financial institution involvement.
- 1.1.2. Ethereum EVM, ERC20, NFTs, & DAOs
  - Ethereum is arguably the most disruptive example of modern blockchain technology. The network took decentralization beyond currency and brought to life decentralized applications (dApps) by introducing the Ethereum Virtual Machine (EVM). Instead of Bitcoin providing an immutable & verifiable public ledger for payments & transactions, Ethereum provides an immutable environment for storing & interacting with applications & code functions (ethereum.org/en/whitepaper). The EVM streamlined the ability for applications built using it to produce complex, immutable & decentralized features such as fungible ERC-20 cryptocurrencies, decentralized autonomous organizations (DAOs), decentralized finance (DeFi), & non-fungible tokens (NFTs). Ethereum is based on a PoW consensus model similar to that of Bitcoin and can only validate a finite & preset number of transactions. Increased utilization of the network causes spikes in gas fees & delayed processing speeds, highlighting the scalability issues of Ethereum. Layer-2 chains are among several proposed solutions to Ethereum’s scalability problems as a layer-1 chain. Layer-2 chains are built on top of it & help process transactions faster & reduce the demand on the layer-1 chain; however, these solutions are still limited in the amount of assistance they can provide.
- 1.1.3. Polkadot, Parachains, & the Paraverse - Fast forward several years past the launch of Ethereum, and the blockchain landscape consists of more than several different layer-1 protocols. Unlike layer-1 chains & their own respective layer-2 chains, there is no native functionality in place that streamlines the seamless communication between layer-1 chains & allows their data to be interoperable between each other. The solution to this, as proposed by Ethereum Co-founder, Dr. Gavin Wood, is a heterogeneous multi-chain system of interoperable & yet unique protocols. The identifiably differing use-cases featured throughout this system would not just be interoperable with each other through a unifying relay chain, named Polkadot, but would also help the network scale in speed in tandem with exponentially strengthening its security (polkadot.network/ PolkaDotPaper.pdf). These interoperable chains, called Parachains, are designed using a blockchain development framework known as Substrate. Substrate is the foundation of the Polkadot relay & its ecosystem; which allows developers to quickly build and launch a blockchain with a variety of feature options available for a wide range of project needs (www.parity.io/blog/what-is-substrate). Nominated Proof of Stake (NPoS) is the process of selecting validators to be allowed to participate in the consensus protocol (wiki.polkadot. network/docs/ learn-consensus). NPoS is a variation of Proof-of-Stake and used in Substrate-based Blockchains such as Polkadot, Kusama, & inevitably, InvArch.
1.2. Intellectual Property (IP) & Protecting IP
- First & foremost, it’s necessary to understand the chronological difference between intellectual property (IP) & its commonly understood forms of protection today - copyrights, patents, trademarks.
- 1.2.1. Intellectual Property (IP) Definition & Scope
  - The consensus interpretation of Intellectual Property (IP) is the creations of the mind, such as inventions, literary, and artistic works (https://www.wipo.int/about-ip). This means that in any instance, Intellectual Property could be anything ranging from a JPEG of a clock melting over a cactus to a computer program consisting of a multitude of interdependent files. Intellectual Property is the egg, whereas protection is the chicken.
- 1.2.2. Protecting Intellectual Property (IP)
  - Copyright is a legal term used to describe the rights that creators have over their literary and artistic works (www.wipo.int/copyright/en). Patents are another form of protection towards more technical IP that wields ingenuity to solve a problem; however, to get a patent, technical information about the invention must be disclosed to the public in a patent application (www.wipo.int/patents/en). Another commonly recognized form of IP protection are trademarks, which are a way of securing a brand’s identity & protecting its unauthorized use or infringement (https://www.wipo.int/ trademarks/en).
- 1.2.3. IP Ownership, Access, & Infringement
  - Owning Intellectual Property (IP) is typically recognized in tandem with some form of protection. Typically, unprotected IP is more so a claim to ownership rather than validated proof of actual ownership. The balance between IP rights and open source is commonly cited as a hard medium to identify. Creators may want to profit from their IP while also considering the implications for the greater good, and how a particular creation can benefit society as a whole (https://michelsonip.com/ traditional-ip- rights-and-open- access-initiatives). Regarding the actual enforcement of the previously outlined forms of IP protection, whenever an unauthorized party knowingly imports, possesses, sells, distributes, sells products of infringement, or transmits an IP with the intent for it to be duplicated. The reality is that it is often an exorbitant cost to attain IP protection. For example, the average & verified costs to secure a patent range from as low as 12,000 USD and fully realized costs reaching closer to 50,000 USD (https://blueironip.com/ how-much-does-a- patent-cost).

IP Assets, IPVM, XCML, & XCDM

2. A Cross-Chain authenticating Invention, Involvement, Inventory, & Investment Arch - InvArch proposes a decentralized & transparent solution for Intellectual Property (IP) rights through the conceptualization of a trustless cross-chain authentication protocol & a cross-chain markup language (XCML) that provides a truly composable indexing framework for deﬁning & representing data-agnostic structures (https://developer.mozilla. org/en-US/docs/Web/XML /XML_introduction). XCML is a format for indexing IP Files in an IP Set that emphasizes simplicity, generality, and usability across a multi-chain, multi-protocol internet. An IP Set would always be the root of an XCML structure. A Cross-Chain Object Representation (XCDM) Is a cross-protocol interface for interpreting XCML tokens sothat IP assets can change their structure, functionality, composition, and metadata (https://developer.mozilla. org/en-US/ docs/Web /API/Document _Object_Model). Additionally, an Intellectual Property Virtual Machine (IPVM) is proposed as a trustless environment for Smart IP contract execution & composability testing https://ethereum.org/ en/developers/ docs/evm/.

2.1. The INV4 Protocol
- The INV Protocol is a truly forward-compatible, data-agnostic, cross-chain standard for tokenizing any form of a digital ﬁle into the form of an authenticated “stem-cell” like non-fungible asset called an Intellectual Property File (IP File). IP Files can be interchangeably combined into folder-like storage structures called Intellectual Property Sets (IP Sets). IP Files & Sets can be fractionalized across nearly every virtual dimension. IP Files & Sets may also be composed of & function as smart contracts, & self-owned IP assets that can demonstrate quine synthesis & meta-programming characteristics (https://cs.lmu.edu /~ray/notes/ quineprograms/).
- 2.1.1. Intellectual Property Files (IP Files, IPFs)
  - Non-fungible tokens (NFTs) are used to represent an immutable record & proof of ownership of unique items such as digital art, real estate, and physical goods (https://ethereum.org/ en/nft/). InvArch builds on this technology in several key ways using new & enhanced NFTs called Intellectual Property Files, also known as IP Files or IPFs. IP Files are non-fungible assets used to certify the existence & authenticity (compared to ownership) of a digital ﬁle, protect the uniqueness of an asset, and streamline its management rights. IP File metadata includes unique & automatically assigned on-chain IDs, interchangeable Set IDs, optional classiﬁcation tags, a copyright license agreement, links to a hosted ﬁle, and a cross-chain authentication (XCA) status.
  - 2.1.1.1. The ERC-721 Standard
    - The “Ethereum Request for Comments #721” is the most common NFT standard & framework. The ERC-721 NFT standard implements an API for tokens within smart contracts and allows a baseline of functionality & preserved distinct characteristics of an asset (https://ethereum.org/ en/developers/ docs/ standards/tokens /erc-721/).
- 2.1.2. Intellectual Property Sets (IP Sets, IP SubSets)
  - NFT collections are speciﬁed groups of NFTs that typically serve to categorize the non-fungible assets together. When an NFT is minted in a collection, it is typically bound to that collection. This serves a logical purpose when considering common NFT use-cases around exclusivity & community at the time of this paper’s writing, such as curated, exclusive, or otherwise themed digital art collections (https://opensea.io/ collection/ boredapeyachtclub). InvArch features a similar grouping system for IP Files; however, with more relaxed restrictions & expanded capabilities. InvArch features truly composable (https://future.a16z.com/ how-composability -unlocks-crypto -and-everything -else/) & interchangeable collections of IPFs called Intellectual Property Sets, also known as IP Sets & redundantly as IP SubSets. IP Sets allow di erent IPFs, regardless of their original IP Set, to co-exist and can be selected and assembled in various combinations to satisfy speciﬁc user requirements. IP SubSets are simply child IP Sets that are stored with their parent, essentially serving as a folder within a folder or other similar XML-like tree structure (https://www.w3schools. com/xml/ xml_tree.asp). Unrestricted ﬁle composability allows anyone using InvArch to take existing programs, modules, and data, and adapt or build on top of them (https://future.a16z. com/how -composability-unlocks -crypto-and- everything-else/). IP Set metadata includes unique & automatically assigned on-chain IDs, a pegged asset ID that serves in place of any owner’s InvArch public key address, optional classiﬁcation tags, a copyright license agreement, and a cross-chain authentication (XCA) status. Ownership of an IP Set is reﬂective in the holdings of its Intellectual Property Tokens (IP Tokens; expanded upon in section 2.1.3.). Common to an ERC998 token on the Ethereum network which can hold both unique non-fungible tokens, as well as uniform fungible tokens (https://ethereum.org/ en/developers /docs/ standards/ tokens/erc-20/).
  - 2.1.2.1. The ERC-892 Standard
    - Permissioned functions are introduced as a way to check permissions between a smart contract and an address, or between one item and a list of items (https://github.com/ ethereum/EIPs/ issues/892). Moving beyond this concept, it is important for certain IP assets on InvArch to feature the ability to have `Permitted`, `Locked`, & `Permissioned` attribute labels in order to not just streamline the process of checking permissions, but also customize access & programmed access qualiﬁers, and helping to prevent composability negligence.
  - 2.1.2.2. The ERC-994
    - Delegated Non-fungible Tokens (DNFTs) are designed to feature a fungible medium of geospace ownership that can be owned and allocated by a speciﬁed delegation tier.Delegation tiers are to be explained as the number of di erent generations of (parent & child) asset relationships (https://github.com/ ethereum/EIPs /issues/994). The ERC-994 standard for DNFTs has since been used as a baseline which has been heavily extended upon in more advanced NFT standards.
  - 2.1.2.3. The ERC-1155
    - Simply put, the ERC-1155 Standard is “a smart contract interface that can represent any number of fungible and non-fungible token types” in order to realize a multi-token standard (https://github.com/ ethereum/EIPs/ issues/1155). What is not simple is the vast amount of use cases that this helps to achieve in terms of representation of nearly inﬁnite values and uses-cases for developers. When you combine these assets with a layer of authentication & cross-chain management, you could then use a “tokenized world of things” to streamline otherwise centralized, costly, & illiquid-bearing processes for IP protection.
- 2.1.3. Intellectual Property Tokens (IP Tokens, IPTs)
  - A crypto utility token serves one or more use-cases extending functionality within a speciﬁc ecosystem that is unique to that token. InvArch institutes completely programmable fungible tokens that can be pegged to an IP Set called Intellectual Property Tokens, also known as IP Tokens or IPTs. Similar to ERC20 fungible tokens, IP Tokens have a property that makes each token be exactly the same (in type and value). As a result, IP Sets & IPFs can utilize IPTs in a very similar manner to how dApps & smart contracts interact with their utility tokens. The intentions for IPT application are for assigning ownership rights (in whole or fractional), streamlining allocation distributions for royalty agreements, providing access rights and authorization tiers to IPFs bonded to an IP Set, determining the voting weight of participants when governing over an IP Set or operating in a related DAO and used for determining consensus (https://www.kraken.com /en-us/learn /what- is-decentralized -autonomous- organization-dao), extending exclusive functionality, providing a native currency for IP-based dApps, and streamlining copyright licensing agreements. It is anticipated that unforeseen use-cases will arise beyond the expectations laid out in the paper as InvArch grows & strives towards being fully realized. IP Tokens are natively interoperable across the entire InvArch protocol and will feature this functionality throughout the Polkadot ecosystem, which opens the opportunity to even more room for opportunities. Having the potential to connect IPTs to the DeFi services of the Acala Network for use cases like Multi-Collateral-Type CDP (https://github.com /AcalaNetwork/ Acala-white -paper/blob /master/Acala_ Whitepaper.pdf), or even be used in community transactions in the Bit.Country metaverse (https://metaversenw.gitbook. io/bit-country /bit.country -metaverse-whitepaper /metaverse).
  - 2.1.3.1. The ERC-809 & ERC-1201 Standards
    - On-chain rental rights covered in the proposal of ERC-809 are extended later in ERC-1201 to feature more liquid & transferable rights. The former introduced a means to rent one non-fungible asset (https://github.com /ethereum/ EIPs/issues /809), whereas the latter introduced a means to tokenize the rental agreement in itself, into fungible tokens (https://github.com /ethereum/ EIPs/issues /1201). This fractionalization of legal agreements pertaining to rent can be expanded to much greater areas as well. Fractional ownership contracts are used in multiple industries, “including the aviation industry, vacation homes, timeshares, and other rental properties.” This means that “parties [account addresses] can divide an expensive asset into shares, thus allowing each owner to receive an interest in the asset for a fraction of the price.” This welcomes entirely new use cases for decentralized applications, including certain times to use a particular asset. As an extension, this functionality can simultaneously “allow multiple parties to share in the ownership of the asset” (https://www.upcounsel. com/fractional -ownership- contract).
  - 2.1.3.2. Synthetic Intellectual Property Tokens (Synthetic IP Tokens, SIP Tokens, SIPs)
    - A combination of cryptocurrencies and traditional derivative assets replicating the cash ﬂows & ownership of another asset (https://whitepaper.io/ document/503 /synthetix-network -token-whitepaper). SIPs are derivative tokens that simulate exposure to other IP Tokens, IP Sets, IP Files, & additional IP assets. Hypothetical possibilities for eternal & unbound liquidity fare feasible using pooled collateral models realized through on-chain IP funding mechanisms.
- 2.1.4. Intellectual Property Duplication (IP Dupes, IPDs)
  - In some use-cases, it makes sense to have a duplicate instance of an IP File or an IP Set. Depending on the protocol housing the data, di erent methods are required to produce an authentic duplication that still preserves the original existence of its parent without infringing on the data. Some instances may involve the cloning of one IP File into another IP File through IP Replication, whereas other instances may involve the authenticated storage & authenticated locking of another digital asset such as an NFT sourced from an interoperable protocol in order to bridge the IP over to an InvArch integrated and/or interoperable protocol.
  - 2.1.4.1. Intellectual Property Replicas (IP Replicas, IPRs)
    - There are instances where, just like forking a repository of code, it is convenient to produce a noted, tracked, & authorized copy of a natively-interoperable IP File or an NFT featuring a standard that is interoperable & composable with the INV4 Protocol. IP Files feature a tag classiﬁcation identifying them as IP Replicas. This serves two purposes: transparency & full disclosure of the status of the asset (if speciﬁed by root owner) & management in order to customize speciﬁc agreements when desired. This is much more control over assets to their actual creators and owners alike when compared to previous “NFT License” standards (https://www.nftlicense .org/). In order to give more freedom to developers, asset creators, and interested parties by making optional customizations streamlined using IP Replicas.
  - 2.1.4.2. Bridged Intellectual Property (Bridged IP)
    - Veriﬁed duplicates of a mutually owned NFT that is stored on an interoperable network or possessing a standard that conﬂicts with INV4 Protocol & restricts full IP Set composability. Such a design could easily be achieved with an Ethereum compatible bridge such as Moonbeam Network (https://docs.moonbeam. network/learn /features/eth -compatibility/) Di erent speciﬁc instances of cloned IP result in di erent IP Tag availability, and as a result, varying freedoms of extended functionality. This allows individuals to essentially wrap their root IP around a new set of standards (https://www.wrappedpunks .com/).
- 2.1.5. Intellectual Property Alchemy (IP Alchemy)
  - Combining two or more IP Files and/or IP Sets to form new IP Set as a result is considered IP Alchemy. Just as an individual may blend a base material into gold, users can blend IP assets into new & sometimes permanent assets.
  - 2.1.5.1. Intellectual Property Bonding (IP Bonding, Bonded IP)
    - The bonding of two assets is when two or more IP Files are locked together in joint relation while remaining distinct in their composition & independent in their functioning. This would be noted in the metadata of the cross-chain markup language (XCML) indexing of two assets, tied by their IPF IDs. Another realization for the representation of one or more IP Files as a single unit, or even additional token(s) representing synthetic or legitimate ownership (https://wrappedkitties. com/), where the single unit has the ability to call compatible batch functions on all IP Sets and/or IP Files in a single Bonded IP.
- 2.1.6. Intellectual Property Splicing (IP Splicing)
  - Sometimes what may be needed is the product of one or more IP Sets bonded and/or wrapped together with or without another IP File native to the IP Set that the new combination would be stored. This is quite simple, utilizing Wrapped IP technologies on an IP File within an IP Set. Even implementing Bonded IP to help achieve indeﬁnite changes realized through IP Splicing. Moreover, when variables align, the root IP could be burned, resulting in a new & authenticated IP File. This feature of asset fusing is a function showcased in NFT based games (https://medium. com/playdappgames /playdapps-nft -merge-is -live -45db1764ed1b) but could be tapped into for more use cases such as the music industry.
- 2.1.7. Smart Intellectual Property (Smart IP Contracts, Smart IP)
  - Intellectual Property Files (IP Files) canstore programs on InvArch that run when predetermined conditions are met. They may be used to streamline trustless followthrough between parties so that all participants can be immediately certain of the outcome, without any 3rd party involvement or time loss. In these instances, IP Files are more accurately referred to as Smart IP, or Smart IP Contracts (https://www.ibm. com/topics /smart- contracts). Smart IP contracts, when combined with their composability & fractionalization features, Smart IP has the potential to highlight the path forward for decentralized AI technology that is community-owned & governed. On-chain IP funding mechanisms, liquidity, & synthetic IP Tokens open the door for allocating wide enough allocations to ﬁt varying use cases of desired community sizes, such as when structuring DAOs (https://consensys.net /blog/blockchain -explained/what -is-a-dao -and-how-do-they -work/).
  - 2.1.7.1. Intellectual Property Virtual Machine (IPVM)
    - Where Bitcoin is a distributed public-ledger, Ethereum is a distributed state machine. The Ethereum Virtual Machine (EVM) features bytecode that the EVM can natively execute. The intent of this functionality is to formally specify the meaning and the ramiﬁcations of a message to an Account. The human-readable form of EVM-bytecode is known as EVM Assembly (https://ethereum.github .io/yellowpaper /paper.pdf). Web Assembly (WASM) is a new virtual machine (VM) similarly designed as a portable compilation target for programs & code and enables deployment on the web for client and server applications (https://developer. mozilla.org /en-US /docs/ WebAssembly). Most importantly, it streamlines interoperability between di erent coding languages into a single compilation target & interface experience. InvArch proposes a distributed cross-chain state machine that natively executes both EVM-bytecode or wasm binaries, depending on the format of the function source. The purpose for such an environment to exist is to provide a distributed IP directory across multiple protocols.
- 2.1.8. Cross-Chain Markup Language (XCML)
  - A markup language is one that is designed for formatting how information is indexed and presented in text. The two most prominently recognized markup languages are HTML and XML. HTML stands for HyperText Markup Language and is a descriptive language that speciﬁes the structure of a web page (https://developer .mozilla.org /en-US/docs /Glossary/HTML). XML stands for eXtensible Markup Language and is a data-description language much more ﬂexible than HTML in that it lets users deﬁne their own tags. This is a highly composable way to store data in a format that can be stored, searched, and shared (https://developer.mozilla .org/en -US/docs /Web/XML/ XML_introduction), and is the base standard that InvArch incorporates in order to not just store IP assets, but also for predeﬁning permissions & even to help realize IP authentication.
  - 2.1.8.1. Cross-Chain Directory Model (XCDM)
    - The Document Object Model (DOM) is an API that is loaded in the browser and serves to represent a document (in our case, an XML document) as a node tree, where each node represents part of the document (https://developer.mozilla. org/en-US/docs /Glossary/DOM). A Cross-Chain Directory Model, while similar, is an API that is loaded into a dApp (and one-day standard) browser and/or wallet interface that allow for interacting, manipulating, and changing the state of IP assets within a directory.
2.2. The Cross-Chain Authentication (XCA) Protocol
- The Cross-Chain Authentication (XCA) Protocol, otherwise known as just XCA, is a means for streamlining & providing the automation of intellectualproperty (IP) authentication by establishing a cross-chain protocol that spreads across and/or integrates with multiple Layer-1 chains. This, in one sense, creates layer-0 level security for IP. In the future, through a mix of cross-chain bridges, oracle services, and other chains built with XCA code natively in their runtime, a protocol for IP authentication & protection can be established through all of Web 3.0. As described by Gavin Wood, founder of Polkadot, Co-founder of Ethereum, and coiner of the term, “Web 3.0 is designed to provide decentralized building blocks for developers to build.” and that Web 3.0 should be viewed as an “executable Magna Carta — the foundation of the freedom of the individual against the arbitrary authority of the despot” (https://gavofyork.medium. com/why-we-need -web-3-0 -5da4f2bf95ab). To fully achieve this, then the ability to protect one’s IP, the start of all great inventions, against the centralized powers that exist to dictate those freedoms is needed. InvArch provides this freedom & further lessens dependency on trust through XCA.
- 2.2.1. Intellectual Property File (IPF) Indexing
  - Data on InvArch, especially that produced through a plethora of diversely-focused applications, ought to be indexed in partnership with an o -chain solution. This will be required in order to provide the most optimal experience for developers to query their data faster & provide cross-chain data accessibility in a more concise manner. Part of how indexed data is organized will rely on Cross-Chain Markup Language tagging; a combination of recognizing the ﬁle type tokenized inside an IP File, its purpose/function, industry labeling, etc. Templates for various text documents will be provided in order to provide a foundation for data ﬁngerprinting (https://docs.microsoft. com/en-us /exchange/overview-of- document-ﬁngerprinting -in-exchange) to better control data indexing and help provide data loss prevention (https://digitalguardian.com/ blog/what-ﬁle -ﬁngerprinting) mechanisms through the InvArch protocol. This will provide an additional and more thorough layer for providing unique identiﬁers for IP File data beyondjust URI & CID data produces from using IPFS (https://docs.ipfs.io/ concepts/content -addressing/#identiﬁer -formats) which demonstrate ﬂaws in ensuring the unique existence of a single ﬁle; one ﬁle can produce multiple CIDs (https://proto. school/anatomy -of-a-cid).
- 2.2.2. Cross-Referencing IPF Data
  - Whenever an IP File is minted, an array of unique identiﬁers is produced. This array consists of IDs ranging between the CID produced by IPFS and the data ﬁngerprint produced by InvArch. This array includes the birth timestamp of the IP File, as well (https://www.gnu. org/software /coreutils/manual /html_node/File -timestamps.php). Additionally, when an IP File is minted, its array of IDs is then iterated over all other arrays of IDs. When a potential match is detected, the older of the two IP Files (as determined by the IP File’s timestamp), would then be ﬂagged. If no match is found, then a veriﬁed status will be provided. The SimHash algorithm could be introduced in order to quickly estimate how similar two sets are (https://www.cs.princeton .edu/courses /archive/spring04 /cos598B/bib /CharikarEstim.pdf); If the SimHash bitwise hamming distance of two phrases is low then their Jaccard coe cient is high. SimHash is useful as it detects near duplicates. This means that near-duplicates will end up with the same hash. For exact duplicates, a consistent hashing mechanism is required.
- 2.2.3. Evaluating & Certifying Authenticity
  - Statuses are determined based on a number rating returned as a result of cross-referencing. Depending on the highest percentage of similarities when compared to another IP File, if any, a number will be returned. If zero (0%) similarities are detected, then the number zero (0) is returned. If the data in one IP File shares fourteen percent (14%) of the contents of another IP File, then the number fourteen (14) is returned. This number is then deducted from one hundred (100), and the resulting number highlights the authenticity ranking of that IP File. A threshold may be set, for example, seventy-ﬁve (75), to act as a baseline score for certifying veriﬁcation statuses. These thresholds can vary depending upon the ﬁle type being cross-referenced. In the event a cross-reference returned a 14% match, then the IP File would possess an 86% authenticity ranking. So long as 86% is at or above the minimum authentication threshold, a veriﬁed status would be provided. If the minimum threshold in this instance was 90%, then an IP File with an authenticity score of 86% would be rejected and updated to reﬂect a ﬂagged status.
- 2.2.4. Cross-Consensus Messaging (XCM)
  - InvArch utilizes Cross-Consensus Message Passing (XCMP), a feature of the Polkadot relay that allows parachains to exchange messages with other parachains on the Polkadot relay (https://wiki.polkadot. network/docs /learn-crosschain #xcmp-cross -chain-message -passing). InvArch will do so by having InvArch Pallets that are both native to InvArch, as well as integrated into other parachains, initiate message requests & the transfer of data, in this case, an IP File’s metadata to & from the InvArch parachain. A copy of this metadata will be stored & indexed on InvArch, where the previously mentioned XCA process would commence and return a message holding the authenticity status of the respective IP File.
2.3 INV4 & XCA Dual-Protocol Governance Structure
- In order to fairly govern over the InvArch protocol, but also provide a means for arbitration or disputes, a multi-body government is proposed. One features the INV4 Technology Council, a body more so to consist of developers, and the XCA On-Chain Judicature, which would serve as a user-base comprised judicial body. The body of $VARCH token holders would maintain the legitimacy of the protocol and its purposes and form a supermajority in either chamber. Similar to Polkadot, through the use of token holdings, the voting weight of a user would be determined; however, this only provides a ﬁnancial representation of the network’s participants versus a general & less ﬁnancially-discriminatory model. So, to combat this, each wallet with a minimum threshold of $VARCH will also be delegated one (1) “Citizens Vote” which serves to mirror the legislative results of the Connecticut Compromise (https://www.britannica .com/topic /Connecticut- Compromise).
- 2.3.1. The INV4 Technology Council
  - The INV4 Technology Council ought to reﬂect a representative democracy system where individuals are able to elect a council of $VARCH token holders who are tasked with ensuring the development & implementation of approved InvArch proposals. The community is free to make proposals; however, the council chooses which proposals to bring to a ﬁnal community vote. Voting weight is determined based on token holdings.
- 2.3.2. The XCA On-Chain Judicature
  - The XCA On-Chain Judicature ought to reﬂect a body similar to the Senate in the united states; where the vote of an individual is not dependent on anything besides their existence in the chamber. As such, a community decided threshold should be determined, something low and close to the cost of one (1) loaf of bread, so that there is little barrier to entry in the process. Only veriﬁed identities, whether on-chain or through possession of veriﬁed credentials (https://www.kilt. io/wp-content /uploads/2020 /01/KILT-White-Paper -v2020-Jan-15.pdf) in a participant’s wallet. The purpose of this incentivized body would be to handle disputes and claims of IP theft and/or ownership.

Token Economy

3. Fueling The Protocol through a common digital medium: $VARCH - The $VARCH token is the native token of the InvArch network. It is required for many necessary functions on the chain such as paying gas fees, participating in on-chain governance, minting intellectual property sets, and forming decentralized ventures, among many others.

3.1. Token Economics
- At genesis, 1 billion VARCH tokens will be minted. The primary security budget is to pay for a parachain slot on an ongoing basis and to incentivize Collators to provide block production services to support the InvArch network.
- 3.1.1. Network Fees
  - 40% of the network fees go to Collators. 25% of the remaining network fees will go to the on-chain treasury. The allocation of these treasury funds will be delegated to an on-chain council which will work in a similar manner to the Polkadot council. These funds will be spent on supporting InvArch-based projects and initiatives from the community members. 35% of all network fees go to IP Set owners via on-chain funding & staking mechanisms.
- 3.1.2. IP Module Integrations
  - To help ensure adoption to other parachains, that they integrate InvArch Pallet Modules, InvArch will take a new approach not seen in previous projects. InvArch will allocate 10% of the total supply, 100 million $VARCH tokens, towards Module Integrations. These funds will be distributed among 10 ﬁrst parachains that integrate the module, each of them will get 1% of the supply. $VARCH tokens will be airdropped equally & directly among the wallet addresses of each integrated Parachain’s token holders. This has the potential to quickly establish $VARCH as one of the most widely distributed tokens in the Polkadot ecosystem (apart from $DOT & Kusama’s $KSM) & will increase awareness of other communities about the project.
- 3.1.3. Token Allocations & Distributions
  - At genesis, the $VARCH token will be allocated as follows; • Seed Funding: 7% (70,000,000 $VARCH), Subject to a 24-month vesting schedule with a 3-month cli and equal vesting in months 4–24. • Strategic Funding: 10% (100,000,000 $VARCH), Subject to a 12-month vesting schedule with a 3-month cli and equal vesting in months 4–12. • Parachain Crowdloan Rewards: 20% (200,000,000 $VARCH), Subject to a 12-month vesting schedule with a 1-month cli and equalvesting in months 2–12. • Ecosystem Development: 10% (100,000,000 $VARCH), Subject to a 12-month vesting schedule with a 1-month cli and equal vesting in months 2–12. • Community Development: 15% (150,000,000 $VARCH), Subject to a 12-month vesting schedule with a 1-month cli and equal vesting in months 2–12. Of the 15% allocated for community development, 10% (100,000,000 $VARCH) is intended as incentive rewards for Ambassadors in the InvArch Ambassador Program. ~3.5% (~35,000,000 $VARCH) is intended for an exclusive and whitelisted community round, prior to any crowdloan campaign. • InvArch Treasury: 20% (200,000,000 VARCH), vesting, if any, is dependent on the reason for $VARCH being allocated from the treasury. • Team & Advisors: 8% (80,000,000 $VARCH), Subject to a 4-year vesting schedule from network launch with a 1-year cli and monthly vesting thereafter. • Module Integrations: 10% (100,000,000 $VARCH), Subject to a 12-month vesting schedule with a 1-month cli and equal vesting in months 2–12.
3.2. On-Chain Intellectual Property Funding
- In order to fund & incentivize innovation at all levels & stages, InvArch incorporates several di erent on-chain funding mechanisms, powered through staking $VARCH.
- 3.2.1. Intellectual Property (IP) Staking
  - Intellectual Property (IP) Staking, otherwise known as just IP Staking, is a means for empowering developments through the allocation of staking rewards and network fees. IP Staking is staking or committing an IP Set to the blockchain in order to participate in one of the following mentioned mechanisms:
  - 3.2.1.1. Intellectual Property Set (IP Set) Bootstrapping
    - Intellectual Property Set (IP Set) Bootstrapping, or just IP Bootstrapping, is a common means of on-chain staking where nominators elect to stake to an IP Set, which fractionalizes the staking rewards among said IP Set and Collators (https://docs.astar. network/build /dapp- staking). This method of staking is designed for whitelisted projects that do not wish to sacriﬁce any of their IP Set’s IP Tokens (IPTs).
  - 3.2.1.2. Intellectual Property Token (IPT) Farming
    - As an alternative to IP Bootstrapping, and a way for establishing liquidity & distribution of an IP Set’s IPTs. Users will be able to choose to divert a portion of their staking rewards to an IP Set in exchange for a portion of that IP Set’s IPTs. Every project will have a predeﬁned cap for this option, for example, “X% of IPT in exchange for Y $VARCH in fees,” so when it reaches a limit, this option will be unavailable.
  - 3.2.1.3. Intellectual Property Set (IP Set) Donations
    - InvArch may feature the ability to donate staking rewards to a project, potentially with the ability to reduce the taxable burdens on participants in their respective physical & legal domains. Rewards can be donated to a project & when this occurs, what actually happens is that the funds are donated to the InvArch Association via the InvArch treasury, for a tax write-o . Then, the InvArch treasury allocates these funds as a grant to the IP Set in question.

Additional Thoughts

4. Challenges & Advancements - Apart from providing the building blocks for decentralized development, InvArch focuses on the certiﬁcation of authenticity of data. Focusing on the latter, InvArch is ignorant of central governments & courts. InvArch serves to act proactively, where one case for ﬂagged data on blockchains is that they are restricted from being used on said blockchains. It is important to note this.

4.1. Enforcement Concerns
- It is imperative to recognize, at least at the start, as a tool that serves to complement and strengthen already existing processes. InvArch records interactions, they are veriﬁable and immutable. These records serve as a ledger for interactions and proof of IP exposure. While disputes and arbitration can be handled on-chain, real-world intellectual property theft will now have an undeniably valuable and strong resource for proof. Matters handled o -chain would be instantly aided by the existence of these records.
4.2. The RMRK 2.0 Standard
- Elaborating on more advanced NFT standards present at the time of the paper’s publication, there is the RMRK 2.0 standard. Key advancements over the preceding NFT standards include multi-resource capabilities, the ability to ‘emote’ over an NFT as a form of communication, conditional rendering, and as showcased in the RMRK Kanaria NFT project, NFT’s owning (equipping) other NFTs (https://github.com/ rmrk-team/rmrk -spec/tree/master /standards /rmrk2.0.0). The RMRK Core goes beyond to showcase a solid foundation of storage classiﬁcations & their respective identiﬁers for classifying metadata & standardizing storage mapping on-chain (https://github.com/ rmrk-team /rmrk-substrate /tree/main /pallets/rmrk -core). Kusama Network ﬁrst showcased RMRK 2.0 NFTs natively on the Kusma Relay, stored as `remarks` before extending this functionality to other developers by the means of a Solidity EVM smart contract implementation. In the end, the RMRK 2.0 NFT Standard realized more reach for implementation throughout the Polkadot ecosystem by expanding on the Unique Network standard for NFT management, and a combination of custom Substrate Pallets (https://github.com /rmrk-team /rmrk-substrate /tree/main /pallets/ uniques). InvArch’s role in this architecture would be similar to the level of the Unique Core in the RMRK Pallets. InvArch, in its place or at a lower level, would extend IP authentication provided by InvArch to RMRK NFTs, natively & as they are minted. It’s also important to note that InvArch does not serve to replace any NFT standard, instead, it is meant to act either a layer deeper or integrated with other technologies.

The Future With InvArch

5. Envisagement For A Future When InvArch Is Fully Realized - There are many exciting tools & applications that can exist because of InvArch. While the hope is that even more exciting applications and industries that could be imagined through this paper become realities, there are a few that are already realized to have revolutionary potential.

5.1. A Decentralized & Authenticated Git Repository
- Through the introduction of a middleware tool, developers could push their code to InvArch, and in doing so, streamline the process of authenticating their code as IP Files. InvArch, by default, provides the architecture by default for a decentralized repository of code. Furthermore, code, programs, applications, etc, could all be authenticated as IP Files & IP Sets featuring custom IP rights & potentially fractional ownership. This opens the door to incentivized open-source code.
5.2. Social Networks for DAOs
- InvArch lays the way for a social network where individuals can secure their ideas, and then identify the roles/skills/talent their missing (and their responsibilities, milestones, terms) & IP Token allocations they would be willing to provide in return, in order to bring their idea to fruition. Also, IP Tokens behind a project could be o ered in exchange for funds from investing methods such as crowdfunding and/or private investing. DAOs can be used to govern over development and can be applied to a plethora of di erent industries, such as software development, music & ﬁlm production, architectural endeavors, social causes, and more.
5.3. Publicly Governed Curriculum
- It would be interesting to see the inclusion of InvArch to provide a decentralized education system or platform where users (or parents) can decide the subjects, courses, content, and so on, that is presented through the system or platform. There is even a possibility that participants could be incentivized, not just for their contributions but also for their participation. Something that could change the way education systems are designed.