Architecture decisions.
WHAT TO PUT ON THE LEDGER
The minimum that must be shared, verifiable and tamper-evident.
WHAT TO KEEP OFF IT
Large data Personal data Anything requiring correction Anything requiring privacy
WHY PERSONAL DATA ESPECIALLY
Immutability conflicts directly with erasure obligations.
WHAT TO STORE INSTEAD
A fingerprint, with the data held conventionally.
WHAT THAT PROVIDES
Proof the data has not changed, without exposing it.
WHAT HYBRID ARCHITECTURES LOOK LIKE
Conventional systems for the application, with a ledger for shared verifiable records.
WHY THAT IS USUALLY RIGHT
It uses the ledger for what it uniquely provides, and nothing else.
WHAT TO DESIGN FOR
Transaction fees varying Confirmation taking time Transactions failing The network being congested
WHAT THAT MEANS FOR USER EXPERIENCE
Operations are not instant, and must be represented honestly.
WHAT TO BUILD
Pending states Status tracking Handling of transactions that never confirm
WHAT TO NEVER ASSUME
That a submitted transaction succeeded.
WHAT TO ESTABLISH
Who pays fees, and how.
WHY THAT MATTERS COMMERCIALLY
Requiring users to hold network assets to use your application excludes most of them.
