Chains, Ledgers, and Law

Legal considerations when building products on decentralize systems

What we'll discuss

  1. System Overview
  2. Product Utilization
  3. Product Promises
  4. Provider Liability
  5. Monetary vs Non-Monetary Intent
  6. Conflicts with Existing Laws & Precedents

Decentralized Identity Architecture

Chains & Ledgers

for anchoring identifiers

Identity Hubs

for encrypted data storage, messaging, and compute

Self-Owned Identity

to enable privacy and control of keys, data, and permissions

  • Only IDs are on-chain
     
  • IDs point to off-chain resources
     
  • Most IDs will be rooted on public chains (e.g. Bitcoin)
  • Data is replicated across all of a user's Hub instances
     
  • Untrusted instances cannot decrypt data
     
  • Transaction volume and transfer speed that is on par with traditional systems

Identity is the dark matter of your life

  • Text, vocal, or visual communications — identity-encoded message transmissions
     
  • Licences, permits, certificates  —  identity-signed declarations of privilege
     
  • Blogs, reviews, comments — self-signed attestations about other identities
     
  • Music, paintings, novels, photos  — identity-encoded asset authorship proofs
     
  • Sales, ads, bids, asks  —  identity-signed signals of offer or intent
     
  • Supply chains, ownership histories  —  a trail of identity-signed proofs

Product Promises

Building a product on top of decentralized ledger often means less control over external factors that can impact the experiences you provide.

 

What kind of feature claims and service guarantees can you make?

Imagine you discovered strong evidence that a party was knowingly harming a decentralized ledger you rely on, with the specific intent to harm your product.

 

What recourse, if any, do you have?

Provider liability

Assume you have only made reasonable promises to users, including disclaimers for any foreseeable issues reliance on a decentralize ledger may present.

 

Will you be able to succeed in disclaiming liability that originates from issues with the underlying ledger?

In many cases, your product may be a pass-through to interaction with/storage of data on a decentralized ledger.

 

 

Where does your liability begin and end for data interactions/storage on a decentralized ledger that you help facilitate?

Monetary vs Non-monetary intent

Transactions on many decentralized ledgers are market-imputed transfers of asset value.

 

Does intent matter? If you create a transaction for the sole purpose of storing data or performing a non-monetary activity, are you subject to laws intended for financial service companies?

It's possible something you relay/handle has no asset value, but later the market begins imputing a value.

 

Do your legal liabilities and regulatory obligations shift under you, forcing you to modify core aspects of your business to remain in compliance with your TOCs and newly applicable law?

conflicts with Existing Laws & Precedents

Many types of transactions and state modifications on a decentralized ledger are effectively immutable.

 

 

How does the nature of an ~uncontrollable immutable record impact laws that attempt to force the option of mutability? Example: Right to Be Forgotten, clawback requirements, etc.

Many products built on decentralized ledgers remove control and observably from external providers and hosts.

 

If users have 'digital castles' and possess the keys, does it affect Third Party Doctrine?

What is required of product providers when government seeks access to user data?

Made with Slides.com