The Kimberley Process Certification Scheme — on the Ethereum Blockchain

In order to bring both transparency and integrity to the KP, my proposal is to put the entirety of the certificate issuance process, including all participants, authorities, observers, agents and parties, on the Ethereum blockchain.

My complete thoughts on diamonds are here.

While there are notable accomplishments of the The Kimberley Process (or not, depending on your point of view), it is also right to insist on continuous improvement, and right to raise alarm about the integrity of the process, particularly where known and constantly exploited vulnerabilities are widely known and proven to exist.

From the perspective of a concerned consumer, an assertion by a jeweler that many of the perceived problems associated with diamonds have been ameliorated because of the existence of the KP, can be deeply unsatisfying after a deeper dive into its internals. Issues such as the scope of the KP being limited to “conflict” diamonds (ignoring important issues such as under-invoicing and transfer pricing) and the very definition of the word “conflict” itself, remain unsettled.

However to me, perhaps the most alarming element of the KP was the integrity of the certificate issuing process, beyond that they are still actual pieces of paper accompanying a physical shipment:

As a result, creation of passable counterfeit KP certificates, or improper use of genuine certificates, is a relatively simple task, and a not-infrequent news event.

Proposed Solution:

Thankfully a framework for a more technological solution exists to address problems related to immutability (inability to change data once created), identity (people are who they say they are), and transparency (public availability of all data). That invention is blockchain, the distributed ledger that belies the cryptocurrency Bitcoin. More specifically and as it regards to potentially solving technical problems for the KP, a newly-released decentralized app development platform on a custom blockchain called Ethereum is a natural fit.

An in-depth technical explanation of both blockchain and Ethereum is beyond the scope of this document. What is important for domain experts to understand about blockchain, is that it is an immutable, decentralized database, where a secure transfer of value can take place without a trusted 3rd party (trustless and yet trustworthy) and a history of ownership of assets can be publicly examined. Obviously, these features of the blockchain can work well when a system is needed to document the transfer of value from one entity to another (digital or non-digital), and allow for the secure approval of that shipment.

What is important for domain experts to understand about Ethereum, is that instead of the most basic element and function being a currency (as in Bitcoin), in Ethereum, it is the execution of a smart contract. These features seem to be a natural fit for a system whose requirements are to securely record a transfer of value, guarantee the identity of the parties involved in the transfer, and assure that those parties are able to participate in the process. Additionally, by making the data of all certificates public (specifically parsel-specific data such as carats and assessed value), it may be possible to more accurately account for the problem of under-invoicing and transfer pricing, which is a problem not unique to diamonds.

My work in progress, as well as a more technical overview of the proposed certificate issuing process, is available here:

https://github.com/triage/KPCSEthereum

I have attempted to implement the requirements of the KPCS certificate issuance process by following the KPCS Core Document as closely as possible. Additionally, I am quite happy to accept comment, collaborators (especially domain experts) and pull requests. As of this writing I have yet to complete the user interface components, but I seek comment on the process and possible need.

How it works:

  1. An instance the contract KPCSAdministrator, and then of KPCS (with reference to the KPCSAdministrator instance) is created on the Ethereum network. In a real-world and official scenario, this would be done once.
  2. Participants, or member countries, create instances for themselves (Participant). They must then be registered with and accepted by the main KPCS instance.
  3. Participant Authorities (ie: The Ministry of Mines and Mining (Zimbabwe)) create instances for themselves, and register themselves with their respective participants. The Participant then recognizes an authority as the appropriate importing or exporting authority, and approves their status.
  4. Agents of a Participant Authority (ie: an individual employee at the Ministry of Mines and Mining, Zimbabwe) create instances of ParticipantAgent for themselves, and register with the appropriate ParticipantAuthority, who then approves their status as an registered employee.
  5. Parties to a proposed certificate (importing, exporting) register themselves by creating instances of Party.
  6. The exporting party creates an instance of Certificate, with references to the appropriate participants (source and destination), and importing party.
  7. Parsels (with data for carats, value and origins (geological if known, from the exporting participant if not) are added to the certificate)
  8. The certificate requests signatures from the importing party, as well as from any agent of a participants importing or exporting authority as appropriate. Importing party and appropriate importing/exporting authorities’ agents each call sign() on the certificate.
  9. The certificate is declared valid, and is registered with the instance of KPCS for it to be official.
  10. Once a shipment transits an international border and is marked as received by either the importing party or the importing authority (or both), the contract is complete.