ConsentChain

India's DPDP Act requires organisations to prove consent was actually given, when, for what, and that the record hasn't been altered afterward. Most consent management today is a checkbox logged in a normal database, which means the company being audited also controls its own audit trail. That isn't really independent proof of anything.

Read through what the DPDP Act actually requires around consent and auditability, then looked at how existing consent management tools store records: almost always a mutable row in a database the company itself controls. That's the real gap. A record that only the party being audited can quietly edit isn't an audit trail, it's a formality.

Built on Algorand, chosen for low transaction costs and fast finality. Consent events get written to the chain instead of living only in a private database, so once a record exists, it's provably unaltered from that point on. A normal database still handles anything operational. Only the compliance critical record needed to live somewhere neither party could quietly rewrite.

The first version tried to put the entire consent record on chain, not just proof of it. That's slow, expensive, and unnecessary. What actually needed to be tamper proof was much smaller than what needed to be queryable day to day: store the full record off chain, anchor a hash of it on chain, and only the hash needs to survive forever.

A working prototype where consent events are hashed and anchored on Algorand, giving an audit trail that doesn't depend on trusting whoever is holding the underlying data.

Compliance problems look like data modelling problems at first glance, but they're really about who gets to be trusted with the record. Once I asked that question directly, the on chain versus off chain split became obvious. Before that, I was solving the wrong version of the problem entirely.