## 4 Application Implementation
### Conflicting Rights Governance
ISRC or ISWC, start date, end date etc. ), there needs to be a way inside Solidity to successfully and efficiently handle this data structure. For that reason and because the aforementioned type of structure was a necessary decision for the implementation to support in the future any type of music or other data, the Solidity RLPReader library is used. The \"checkClaimStatus\" method extensively uses this Ethereum RLP decoder library (RLPReader) in order to translate the imputed claim data information in an internal data structure appropriate for conversions in desired data types such as bytes, string, uint; though a further deep dive into the details of the RLPReader library is out of the scope of the paper. Afterwards, the \"checkClaimStatus\" smart contract method uses the private mapping of claims to detect firstly the claims that have the same international standard code (ISRC or ISWC). For each of them, it compares their data with the input claim data and determines if between the two there is date overlap, use types overlap or right types (sound recording or musical works, respectively) and territory overlap. If there exists such an overlap, then the method executes a special code part in the smart contract which is dedicated for overlapping claims. In general, the user can try to perform create, update and delete operations on a new or existing claim when this method is called privately inside the Claims contract. Overlapping claims management is fundamentally relevant with the max split field of a claim (uint16 maxSplit, Figure 7). In principle, a claim's max split field indicates exactly the total sum of its own percentage split plus the percentage splits of all the claims with which it overlaps, as displayed in the diagram below (Figure 9). If a max split of a claim is greater than 100, then the status of the claim is marked as a conflict. Otherwise, it is marked as claimed. When a pair of overlapping claims is detected, then the max  
Figure 9: Explanation of a claim’s max split field in a Venn diagram. All max splits here are greater than 100.  
split of both claims is recalculated on-chain and their corresponding statuses are updated accordingly. For instance, in Figure 10, it is made clear that two claims (Claim 2 and Claim 3) may have overlap, but their max split may not always exceed 100. In parallel with the \"checkClaimStatus\" method's max split percentage handling, the user's claim inbox is updated accordingly through the corresponding Solidity smart contract. When new claim conflicts arrive, they are added to the user's inbox, and when already conflicting claims are turned into claimed ones, then they are withdrawn from the inbox. These operations are executed with simplicity through the elegant interoperability of the Claims contract with the Users contract (see Section 4.4), while the first one calls the corresponding methods of the second one in order to configure the user inbox when necessary. Conclusively, the on-chain conflicting copyrights governance of the presented application leverages the immutability and privacy protection of the permissioned blockchain in order to create a secure system where CMOs and their Members can unquestionably exchange musical rights information and store claim data under the guarantee and preservation of such a system. The whole schema can benefit and can certainly be applied to other use cases in wider and broader industries. The core evaluations of the entire system are explored in Section 5. In this paper, the presented conflicting rights governance precedes the monetary incentive mechanism, which will be analyzed in the following section.