Skip to end of metadata
Go to start of metadata


The DG name, acronym and abbreviation must not include trademarks not owned by the Organization, or content that is infringing, harmful, or inappropriate.

Blockchain and Smart Contracts (BSC) DG


Please provide a clear statement of the topic, purpose and/or motivation for the formation of this DG.

The purpose of the Kantara DG is to initiate a broad discussion on various aspects of smart-contracts and blockchain systems.

The advent of the Bitcoin currency system has generated interest in permissioned blockchain systems not only for the purposes of achieving an immutable “trustless” distributed ledger, but also for the execution of smart-contracts (code) on the blockchain P2P nodes that conforms to a given consensus algorithm.

Among other things smart contracts offers something previously attainable in paper contracts, namely the programmability of parts of the contracts whose execution is based on real-time input from external sources of data (e.g. stock ticker feed; weather reports; IoT sensor feeds, etc).  When multiple nodes on the P2P execute the same smart-contract or execute parts of an interconnected contract, a certain degree of immutability of the outcome can be achieves based on the choice of the P2P consensus algorithm. This in turn provides a corresponding degree of assurance among transacting parties that the execution of the smart-contract has reached completion.

There are, however, a number of challenges in both the technical and legal spheres before smart contracts can be adopted, deployed and obtain legal standing.

Among others, the topics to be covered are as follows:

  • Smart contracts specification language (e.g. CommonAccord)
  • Legal aspects of Smart contracts specification language
  • Digital identities of entities specified in smart contracts
  • Distributed access control to private and shared repositories of smart contracts.
  • Legal status of consensus algorithms
  • Authenticated data sources/feeds
  • Agreements for data collection, use and disclosure (AKA Consent Receipts)


Proposed DG Chair subject to confirmation by a vote of the DG Participants.

  • Thomas Hardjono (co-chair) – technical
  • Jim Hazard (co-chair) – legal


Anticipated audience or users of the work.


Creative Commons Attribution-­‐ShareAlike 3.0 Unported or another Organization approved Intellectual Property Rights Policy Option to cover any copyright material that may be produced as a result of DG Participants’ posts to the wiki or email archives.


Names, email addresses, and any constituent affiliations of at least the minimum set of proposers required to support forming the WG. At least 3 proposers must be listed. At least 2 of the proposers must be Kantara Initiative Members - current members list

  • Thomas Hardjono
  • Eve Maler
  • Jim Hazard

  • No labels


  1. This is great!  As a result of discussions at the MIT-May23 conference (sponsored by Kantara), the relationship between CommonAccord and databases (including blockchains) seems clearer.  Also some implications for access management.  To crystalize these thoughts, I tried to define a JSON-ish query to a database that should return CommonAccord documents:

    This is framed in description here:

  2. There is a great deal of overlap (and close fit?) between CommonAccord and IPLD - the linking of IPFS.  (twitter: @chrisLundkvist) has pointed this out.  I suggest that we look at this more closely. 

    The definition of the linking language seems to be here:

    Aside from the "punctuation" (@xmlgrrl) differences, IPLD seems mostly to be a superset of CommonAccord.  It allows a much broader range of links and of materials to be accessed.

    The major restriction of IPLD vis-à-vis CommonAccord is the hard-wiring of a character ("/") to the concatenation of objects.  The actual choice of the character seems awkward, suggesting a traversal of file folders, but perhaps there are technical reasons they can't or don't want to use periods (".").   Setting that aside for the moment, it seems that an IPLD set of records could express CommonAccord and return exactly the correct value if:

    Instead of saying something like-

    Sold to {Buyer.Name.Full}.


    Sold to {Buyer/Name/Full}.

    And instead of-


    IPLD (in YAML)-


    /: U/id/acme_incorporated

    (with appropriate binding of the conventional "file name" to the hashed name of the file)



    /: QmCCC...11

    (direct link)

    It is unclear to me if one can say-

    Name/Full: "{Name/First} {Name/Last}"

    Name/First: "Jane"

    Name/Last: "Smith"

    or if you MUST say-


    Full: "{First} {Last}"

    First: "Jane"

    Last: "Smith"

    In this example, the second is of course better, but there are situations where you might want to say:

    Buyer/Name/Last: "Smythe"