DEV Community: Fred Santana

How a Blockchain Transaction Works: From Start to Final Block

Fred Santana — Tue, 24 Mar 2026 15:16:32 +0000

Why should a compliance professional care about this?

I spend a good part of my days thinking about how to protect personal data. LGPD (Brazilian General Data Protection Law), privacy policies, legal bases — that's my world. When I started studying blockchain seriously, I realized that it wasn't enough to understand what the technology does. I needed to understand how information enters this network and why, once it's in, it's practically impossible to remove it.

This "practically impossible" is what keeps those who work with compliance awake at night. But before entering this debate — which will be the heart of this 30-day campaign — we need to understand the basic mechanics. How does a transaction originate, travel through the network, and become permanent?

I'll explain without a single line of code. I promise.

The analogy of the digital notary office
Think of a notary office. You go there, sign a document, the notary recognizes your signature, registers everything in a book, and stamps it with the date and time. From that moment on, that record officially exists.

A blockchain transaction follows a similar logic — only without the notary. There is no person or company at the center deciding what is valid. The entire network plays this role. And the "registry book" isn't kept in just one place: it's copied on thousands of computers around the world.

Does that seem excessive? It's precisely this excessiveness that makes things secure. And it's this same excessiveness that creates the challenge for the LGPD (Brazilian General Data Protection Law).

The five stages of a transaction

Creation — "I want to register something" It all starts with an intention. Someone wants to send a value, register data, or perform an action on the network. This intention becomes a "transaction" — a package of information that basically says: who is sending, to whom, and what.

Think of it like filling out a form at the registry office. You haven't registered anything yet — you've only written what you want to do.

Connection with compliance: even at this stage, if the data being registered is personal, the LGPD comes into play. Article 7 requires a legal basis for any processing of personal data. The simple creation of a transaction containing a person's data is already "processing" under the law.

Signature — "I confirm that it's me" Before submitting the form, you need to prove that it's you. In a physical notary's office, this would be your notarized signature. On the blockchain, there's a mechanism called a digital signature.

It works like this: you have two keys. One is like your safe's number (public — anyone can see it). The other is like the combination that opens the safe (private — only you know it). When you "sign" a transaction, you're using your private key to create a unique mark that anyone can verify using your public key, but that no one can forge.

It's as if your signature at the notary's office were impossible to copy. Literally impossible — not difficult, impossible.

Connection to compliance: the public key, although it doesn't contain your name, can be traced back to you under certain conditions. Article 12, §2 of the LGPD (Brazilian General Data Protection Law) states that data that can be used to identify someone, even indirectly, is personal data. A blockchain public key can fit this definition — and this is one of the most important debates in the field.

Propagation — "Spreading the word" After being signed, the transaction is sent to the network. Imagine you handed your signed form not to a notary's office, but to a public square full of people. Each person who receives the information passes it on to others.

In a few seconds, thousands of computers (called "nodes" of the network) already have a copy of your transaction. It is not yet confirmed — it is in a "waiting room" called a mempool, waiting to be processed.

It's as if the notary's office had a queue: your document has been received, but it hasn't been stamped yet.

Validation — "Checking if everything is correct" This is where the notary's office replaces the notary. Specialized computers (in the case of Bitcoin, called miners; in other networks, validators) take transactions from the waiting room and check:

Is the digital signature valid? Does the sender actually have what they claim to have?

Does the transaction follow all the network rules?

If something is wrong—a forged signature, insufficient funds, any irregularity—the transaction is rejected. No appeal, no "workaround." The rules are the same for everyone.

Imagine a group of independent accountants, each checking the same spreadsheet. If the majority agree that the accounts balance, the transaction is approved.

Compliance connection: this decentralized validation is fascinating from the perspective of Article 46 of the LGPD (Brazilian General Data Protection Law), which requires "security measures capable of protecting personal data." Distributed consensus validation is, technically, one of the most robust ways to guarantee data integrity that we have ever invented. But who is the "controller" responsible for this validation? The entire network? Nobody? That's another open question.

Inclusion in the Block — "Stamped and Archived Forever" Approved transactions are grouped into a block — think of it as a page in a notary's ledger. This page receives a unique stamp (called a hash) that functions like a fingerprint: if someone tries to alter even a comma on the page, the stamp changes completely, and everyone notices the fraud.

But the crucial detail is this: each new page contains the stamp of the previous page. This creates a chain — hence the name blockchain (chain of blocks). To alter an old transaction, you would need to redo all subsequent pages on thousands of computers simultaneously. In practice, this is unfeasible.

The transaction is now permanent. It's in the ledger. The ledger is in thousands of places. No one can tear the page out.

Connection with compliance: and this is exactly where the paradox lies. Article 18, item VI of the LGPD (Brazilian General Data Protection Law) guarantees the data subject the right to the deletion of personal data. But how do you delete something from a book that, by design, was made to be unalterable? This conflict between technical immutability and the legal right to be forgotten is the theme we will explore throughout this campaign.

What I learned building DPO2U
When I started developing DPO2U — a tool that attempts to reconcile blockchain with data protection — I thought the biggest challenge would be technical. Code, contracts, infrastructure.

I was wrong. The biggest challenge is conceptual. It's understanding that blockchain wasn't designed with privacy in mind. It was designed with transparency and immutability in mind. And the LGPD (Brazilian General Data Protection Law) wasn't designed with blockchain in mind. It was designed with traditional databases in mind that can be edited and deleted.

These two logics are on a collision course. And understanding the mechanics of a transaction — how it is created, validated, and becomes permanent — is the first step in understanding why this collision is so difficult to resolve.

Where are we going tomorrow?
Now that you know how a transaction becomes irreversible, the natural question is: what if I need to delete this data? If the LGPD (Brazilian General Data Protection Law) gives me the right to request the deletion of my information, how does this work in a system that was built to never forget anything?

On Day 3, we'll dive headfirst into this conflict: the immutability of the blockchain versus the right to be forgotten. This is where the privacy paradox gets really interesting.

What is Blockchain: A Technical Guide for Compliance Professionals

Fred Santana — Mon, 23 Mar 2026 14:11:27 +0000

Why a DPO Needs to Understand Blockchain

I’m Fred, founder of DPO2U. In recent months, I’ve been publicly building an on-chain compliance ecosystem, and I’ve encountered a problem that few admit exists: the technology that promises perfect auditability can violate the very law it’s supposed to protect.

This conflict has a name in academic literature. De Filippi and Wright, in Blockchain and the Law (2018), already warned that immutability would create direct tensions with the right to data deletion. In my Zettelkasten, I registered this as the Paradox of Immutability (ZK-20260125-013): the virtue of blockchain for integrity is its vice when personal data needs to be deleted.

This article is Day 1 of 30 in the “The Privacy Paradox” campaign. My goal: to explain, without unnecessary jargon, what you need to know about blockchain to make informed decisions. Not to become a programmer, but to avoid being deceived by those who sell magical solutions.

The Promise: Why Blockchain Matters for Compliance

Imagine your company needs to prove it obtained consent from a data subject on a specific date. Today, this proof is usually in an internal database controlled by the company itself. If there is litigation, the other party might question: “who guarantees that this record hasn’t been altered?”

In the DPO2U Whitepaper, I documented the vulnerabilities of the current system: privacy policies in editable PDFs without a trace, consent records in deletable spreadsheets, DPIAs with manual versioning. Which version is valid?

With blockchain, the consent record would be in an immutable ledger verifiable by third parties. No one would need to trust the company’s word. Think about the applications:

Consent record with an inviolable timestamp, an audit trail that no system administrator can tamper with, proof of compliance verifiable by regulators without depending on the company’s good faith.

It’s like replacing that Excel file that “proves” compliance with a digital notary record that no one controls alone.

Public vs. Private Blockchain: The Distinction That Matters

Not all blockchains work the same way, and this distinction is crucial for compliance.

A public blockchain functions like a mural in a public square. Anyone can read all the records. Bitcoin and Ethereum are examples. In them, recording a CPF (Brazilian tax identification number) or email address would be like writing personal data on a billboard, visible forever to everyone.

A private (or permissioned) blockchain functions more like the internal system of a consortium of companies. Only authorized participants can read and write. There is more control, but less decentralization.

For compliance professionals, the key question facing any blockchain solution is: who can read what is recorded? If the answer is “anyone on the internet,” Article 46 of the LGPD (Brazilian General Data Protection Law), which requires technical measures to protect personal data, is at risk.

Five Questions Every DPO Should Ask Before Accepting a Blockchain Solution

Is personal data on-chain or off-chain? If the answer is on-chain, immediately question compliance with Articles 16 and 18 of the LGPD (Brazilian General Data Protection Law).
Is the blockchain public or permissioned? This defines who has access to the records and directly impacts Article 46 (security measures).
Is there a deletion or anonymization mechanism? Immutable blockchain + personal data = regulatory risk. Ask how the provider intends to handle deletion requests.
Who is the data controller? In decentralized networks, the chain of responsibility foreseen in Article 5 of the LGPD becomes unclear. Someone needs to be responsible for compliance.
What is the legal basis for processing? Article 7 of the LGPD requires a legal basis for any processing. “It’s on the blockchain” is not a legal basis.

Day 1 of 30 — “The Privacy Paradox” Campaign. References: De Filippi, P., & Wright, A. (2018). Blockchain and the Law. Harvard University Press. | LGPD, Law 13.709/2018. Next: Immutability vs. Right to be Forgotten