Some questions about a license management use case

Question

I would like to ask your help and suggestion about below use case what are related to our new business case, a CorDapp which will be used to manage software license usage and management.

Does Corda has a pre-defined structure or approach to define the parent and child relationship between different states, for example, one contract state(main contract) has two child contract states(two types of license contracts)

If we want to track the license usage on blockchain, is that a good direction to ownable state for licenses? Our current thought is Party A(License Provider) and Party B(License consumer) has one agreed contract that Party A will provide Party B 100 licenses to be used, but charge will only happen after one license is activated by Party B. So from Corda’s backend process, Party A will issue 100 licenses initially which owner is PartyA, and this shared fact will be initialized as a transaction and will be added to both party’s ledger. Then periodically license usage data will be extracted from Party A’s system and updated the ledger by initializing a transaction, we will use “Move” flow to transfer the license state’s amount and owner. For example, if Party B activated 40 licenses, then Party A’s license state amount will become to 60, and there is another new state which owner is Party B and amount is 40. I thought I should use ownable state for this use case after reading some Corda documentation about linear state and ownable state, but not sure whether my understanding is correct

What is the best practice from Corda about how to design a dynamical contract terms which can be used in smart contract(verify menthod conditions). For example, in the initial version of license management process, two types of licenses and their price will be defined as contract terms, and we plan to define them as the state’s properties(meta data). If later there are one new type need to be added, how should we best handle this situation. Is there any dynamical approach to define the state’s properties/meta data? Our ideal approach is initially there is no any terms defined(no license type pre-defined), and allow user to add different type of license with their price information dynamically on UI, then these dynamically defined contract terms will be stored in CorDapp and can be used in later phase, and this approach can be easily to be “copied” to different providers. Is this possible to do?

Answer 1

Very interesting use case and scenarios. We have not formalized best practices for parent child states in api wrappers, but you can treat the collection of states using the same relational database model as long as your transactions also keep pointers updated.

Our thinking for state representation covers 3 hierarchical scenarios: 1 - portfolio of assets - like an etf or index grouping multiple assets. This can be moved as a new portfolio asset representing a tether to the existing asset data or a grouping function 2 - asset itself - this is a linear state that has a life cycle of events that influence it. Think of this like the company ref data behind the equity 3 - fungible asset representation - cash flow fungible staye that can reference the asset's linear id - think of issued shares for the equity

In this case, the 2 & 3 scenarios have the ref data to fungible state relationship. The fungible state can store the reference to the asset's linear ID and the asset can store an array of owners of the equity. Depending on your queries, you can also store another relational table for mapping different foreign and primary keys. The careful part is taking into account this logic linking when executing transactions that change issuance or ownership

For the standard Ethereum factory pattern, cordapps can be broken up into multiple functions. For example, the obligation cordapp uses the corda-finance-1.0.jar package to share different library functions and definitions on self issuing cash and cash properties.

Coming back to the asset example, we have an interest rate swap example cordapp that has contract code defining the known fields in a standard irs ISDA contract. From this template, you can deploy any irs type of state by defining the field properties like maturity date and interest rate.

I imagine the license use case can create similar fields for types for how the business logic or contract code would see it evolve. This also brings to light a tool gap for wrapping a workflow management tool or interface above the corda fundamentals.