Why on-chain consent?
Why on-chain consent?
How to leverage blockchain tech to lower the risk and cost of data compliance.
Compliance management usually is expensive AF. It requires a doc trail, rules, policies, auditing... it adds up, particularly in shifting legal landscapes (like data). On-chain consent can both improve data availability and make a sizable dent in costs.
By on-chain consent, we mean:
On-chain - utilizing blockchain technology. More specifically, immutability, decentralization, and tokenization.
Consent - an agreement by the owner granting permission to a second party to use an amount of data (point, pool, stream) —most commonly granted to businesses, often for specific use cases.
Consent? Isn't that just a Terms of Service or Privacy Policy agreement? Only in the conceptual sense. In actuality, it's far more nuanced and so easy to screw up.
For starters, ToS agreements are not a one-time magic do-anything you want —from Ironclad:
For your Terms and Conditions to be enforceable, you have to prove that a particular user accepted a particular version of a particular agreement at a specific time.
Regardless of what's in your ToS, you must follow the applicable jurisdiction laws. Per Bloomberg Law —Zillow, Lowes, and Expedia are all being sued for using
software that allows the companies to record mouse movements, keystrokes, search terms, information inputted into the websites, and pages and content viewed during visits, all in violation of the Pennsylvania Wiretapping and Electronic Surveillance Control Act
Privacy policies? Well, they're a double-edged sword. If you violate your own policy, you get sued. Way back in 2015 (lawsuits are slow), Vizio's (TV manufacturer) privacy policy stated
the company doesn't combine video-viewing data with "personal information.
They did; they were sued ($17M), and now smart TVs require affirmative consent to collect viewing data.
Maybe the most telling is the $150M fine Twitter just paid for deceptive business practices —using 2FA phone numbers and email addresses for targeted advertising.
Say you get all that right (all the time) —you've got an on-staff DPO. What about the growing list of explicit consent requirements?
iOS: IDFA (ATT), location, camera, microphone, contacts, notifications, etc.
Android: location, camera, microphone, SMS, storage, etc.
Web: cookie consent popups everywhere.
Now you must comply with various platforms and specific dataset rules. It's a lot, and more regulations are coming.
In summary, data consent requires recording who agreed to what and applying a complex set of rules that inevitably keep changing.
So, how can we use blockchain (preferably TIKI's) to make this mess better/easier? If we can move consent on-chain, we immediately have an immutable, auditable trail —documenting who agreed to what and when.
Moving consent on-chain is easy; it just requires a transaction containing a payload representative of the granted (or revoked) permission.
On EVM-compatible blockchains, it can be accomplished with a smart contract and the transaction data field (tokenization). On TIKI's blockchain, it's even easier; you just create a data consent transaction (0 smart contract development).
Consent doesn't have to be complex —it could be as simple as a link to the agreement (e.g., ToS). Transactions are timestamped and signed by the creator's wallet (user).
At TIKI, we take it a step further. Short answer: to make creating automated rule processing and auditing easier.
First, we create a transaction defining data ownership (dNFT) —you can't grant consent for something you don't own.
A dNFT contains:
Source - an identifier for the data origination/creation (provenance) —typically reverse FQDN for the application.
Type - the type of data represented; supported values are point, pool, or stream.
Contains - a list of tags representing the data (e.g., email_address)
About (optional) - documents the reason for the ownership grant
Next, the consent transaction adds the following to the chain:
Destination - defines one or more companies/services that the consent applies to.
About (optional) - documents the reason/use for consent
Reward (optional) - a reward promised to the user in exchange for consent
Expiry (optional) - the date the consent is valid until
AssetRef - the transaction id for the dNFT
Using these two types of transactions, we can now create varying consent levels for data as granular as a single point or as coarse as an entire application. We use the latest consent for a given dNFT, making it easy to amend or revoke consent. Simply create a new consent transaction with the matching AssetRef.
---
Using the immutable consent log, we can create automated rules and auditing, all leveraging decentralized processing (low cost and crazy fast).
At TIKI, we do this by wrapping our unique blockchain node in client SDKs. These client SDKs, in real-time, cache the applicable dNFTs and validate consent granted on any outbound data transactions. Meaning without explicit consent, data will not leave the user's device.
side note: this means no backend changes are required.
Currently, at TIKI, we don't perform auditing on or enforce any rules around the types of consent that can be granted. SDK implementers are responsible for abiding by their internal policies and applicable laws.
Blockchain technology's data structure and decentralization make it a unique solution for consent management. Most of the effort, if not all of the effort, from logging to auditing, can be automated and executed at unparalleled costs and accuracy.
For perspective, a dNFT or consent transaction on TIKI's blockchain costs ~$0.000000007 one-time —no compute, hosting, storage, networking, or otherwise.