I once consulted for a startup in Germany wanting to use Sign Protocol to store KYC attestations — records verifying identity stored on the blockchain. The first question from their lawyer made me pause for quite a while: if a user requests data erasure under GDPR, can Sign comply? I did not have an answer.

In 2014, Mario Costeja González won a lawsuit against Google at the European Court of Justice. Google was forced to delete information about him from search results. Since then, the right to be forgotten has become enforceable law in the EU. GDPR Article 17 extends this right: anyone can request the deletion of personal data if the data is no longer necessary for the original purpose.

Sign Protocol is building something directly opposed to that principle. Not because Sign lacks foresight. But because immutability is a core feature of the architecture. An attestation written on the chain cannot be erased. This is exactly what Sign's customers are paying for.

The problem begins when Sign contracts with organizations in jurisdictions with GDPR. They are building infrastructure that, technically, cannot comply with a legal requirement that could arise at any time.

This is the "erasure immunity conflict". The system is designed to be unerasable in legal environments where erasure of information is mandatory.

Sign has some technical solutions. ZK selective disclosure allows users to prove an attribute without revealing the original data. If sensitive data only writes a hash or commitment, then theoretically there is nothing to erase.

But the issue is not theoretical. When a developer accidentally writes personal data directly onto the chain — this has happened, it's not hypothetical — no one has a mechanism to erase that record. Sign cannot erase. The developer cannot erase. The affected users still have the right to request erasure under GDPR.

Who is legally responsible? Under GDPR, the data controller — the organization that decides the purpose and means of processing personal data — is responsible for complying with the right to erasure. If a startup uses Sign to store an attestation containing personal data of EU users, that startup is the data controller. But they are using a system that, by design, cannot delete data.

When forced to choose between complying with GDPR and maintaining the integrity of the blockchain, one of the two must lose.

This is not Sign's fault. This is a collision between two systems designed with fundamentally opposing assumptions. Blockchain assumes data must exist forever to be trustworthy, while data protection law assumes the opposite: data must be erasable to be lawful. Sign is building at that intersection without a public answer to this erasure immunity conflict.

This does not prevent Sign from deploying in jurisdictions without GDPR. Kyrgyzstan, Sierra Leone, UAE are all outside the direct scope. But when Sign expands into the EU, or when projects built on Sign serve EU users, the erasure immunity conflict becomes a real legal issue.

Anyone building on Sign for EU users needs to ensure one thing before any disputes arise: do not write personal data directly on-chain, only write hashes or commitments, and document clearly in the system architecture. This is not best practice. This is the minimum requirement to avoid falling into an erasure immunity conflict as a GDPR-violating data controller.

That is also the reason I follow Sign not just through the number of deployments, but through how they address erasure immunity conflict in jurisdictions with the right to erasure.

Immutability is a feature. Until the law requires it not to be a feature anymore.

@SignOfficial $SIGN #SignDigitalSovereignInfra