_** Updated 26th July 2025: Im not sure what happened to the source code for this one, I think its on an old broken laptop, so unfortunately I cannot open source the project, and the event diagram doesnt seem fully correct either, but its still a really cool idea which I mostly get the idea, and I like it. Theres a lot of screenshots from my own implementation as well.
Contract to product transaction ledgers
The idea behind this project was to develop a private but fully available, unecrypted, readable centralised transaction ledger that can be queried for a detailed history on the ownership, history, and exchange of different types of items or products on the ledger, or a represnetation of physical products and goods.
The C2P framework is a private network with this ledger at its core, used to store user accounts and products, and contracts. A contract is an abstraction of this framework that describes the exchange or transfer of products between other entities on the ledger. An products, user, or contract is is a word or name, and is allocated and managed similar to domain name in Public Key Infrastructure (PKI).
The motivation for this project was to provide transparency and buyer security in the chinese second hand car market, which apparently are notoriously problematic. The key problem that this framework tries to solve is maintaining a detailed vehicle history, openly available to prospective buyers.
The ledger would contain inforation such as the date and location of original purchase, previous ownership, services, accidents, and more. Eventually, I hoped it would be possible to implement that certain parts of the ledger be updated automtically, rather than particular events such as accidents must be recorded manually, for example voluntarily by vehicle owners.
Products must have a physical identifier intrinsically bound to the product hardware, such as a serial number. User accounts must also be tightly bound to a single person, and KYC verification in some cases may also be necessary. Designated permissioned accounts would have the ability to create products. All entities must be tracked on the ledger from creation have an original point at which they began.
The two class diagrams illusrate the idea in more detail gives some of the basic components and object abstractions required, such as contracts, accounts, and products.
This image shows the dynamic relationship between products and contracts. A single product may be referenced my multiple contracts, and a single contact may reference multiple products. A contract must also also reference two accounts: The buyer/owner/giver and the seller/receiver. The process of querying the ledger and tracing back the history of a product to see what contarcts it has been used in, who are the participants of those contracts, and what other products were involved in those contracts can be seen here.
The sequence of events illusrated below shows how a permissioned account Am creates 5 proucts, P0-4, and then sends a contract C0 to A 0 products. The double blue lines show how this contract (C3) contains all 5 of all these original products. A0 then decides to keeps P0, and sends another contract (C1) to A 1, that contains the remaining 4 products P1-4. A1 then decides to keeps P1, and sends another contract (C2) to A 2, that contains the remaining 3 products P2-4. This sequential series of events continues with each subsequent contract containing 1 less product than the contract before until each account A0-5 owns a single product.
At this point, given any entity on the ledger we can see traceback to the creation of the entity and see the full history of transactions or contracts that refrence either directly or indirectly this entity. The sequence of events given in the example above was purposefully simplistic, but in a real world use case, with rich and complex and transactions histories updating continuisly, it would, in theory, be possible to build an API or interface that could query to form a complete picture of all relevant events recorded on the ledger from any single starting point.
My own implementation, for fun, and to demonstrate this idea, I developed in Java and served locally on a Tomcat servlet container. The web interface I wrote in Vanilla JS, HTML5 and SAS/CSS. I didnt use any component frameworks, although I did use quite a lot of some popular libraries. This implementation has quite limited functionality, but it partially implements some crucial framework features, such as creating a user account, writing and signing contracts, creating and transferring products, and querying the ledger history.
The project was never quite finished yet, and I couldnt find a reasonable way to deploy it for a long period either, so currently I am just able to provide screenshots from running it locally.
