A small example makes this easier to see. When you cross out a word in a notebook, the word is still there. You can see what was written, you can read it, and you know it existed. The line through it tells you someone decided it was wrong. It does not make it gone.
From what I can tell, parts of Sign Protocol seem to work in a way that resembles that crossed out word.
The protocol can create on-chain attestations, depending on how data is stored. When an issuer makes a claim about someone, that claim is written permanently to the blockchain. The documentation is fairly direct about this. It describes attestations as tamper-proof and finalized. The design is intentional. The point is that records cannot be quietly changed or erased after the fact, which matters enormously for accountability and trust.
But what happens when a record is wrong from the start?
Based on the documented architecture, there doesn’t appear to be an update or delete function. The only corrective action available is revocation. When an issuer revokes an attestation, two things change inside the record: a flag flips from false to true, and a timestamp gets added showing when revocation happened. Everything else stays exactly as it was. The original data, the attester address, the recipient address, the schema, the creation time. All of it appears to remain visible across the networks the protocol currently supports, which currently includes Ethereum, Base, Arbitrum, Polygon, and about ten others.
The prescribed correction pattern, which the documentation doesn’t seem to fully formalize as a workflow, involves revoking the wrong attestation and creating a new correct one that links back to the old. The linkedAttestationId field is the mechanism for this. It is described in the documentation in roughly one sentence. What you end up with is two permanent records on-chain: the wrong one and the correction. The wrong one still exists. The correction sits alongside it. Anyone with blockchain access can read both.
I want to be careful not to make this sound more alarming than it is. Traditional record systems also struggle with corrections. Medical records in existing hospitals carry a similar structure, where errors are documented as amendments rather than replacements, and the original wrong entry stays in the chart. Criminal records in many countries persist even after exoneration. Credit reports carry disputed items rather than deleting them. The problem of permanent incorrect records is not something blockchain invented.
But what blockchain changes is the scale and distribution of persistence. When an incorrect record lives in one hospital's database, fixing it means finding that database and updating it. When an incorrect attestation lives on fourteen public blockchains simultaneously, the wrong record exists in every node of every network, permanently, with no administrator who can overwrite it.
This sits in tension with something I think Sign Protocol has not yet fully addressed. In Europe, there’s a concept often referred to as the ‘right to erasure. The idea is that a person has the right to have their personal data genuinely removed under certain conditions. In April 2025, the European Data Protection Board issued guidelines on blockchain and personal data processing that were quite direct. The guidelines said technical impossibility cannot be used to justify non-compliance, and that if GDPR-compliant processing cannot be achieved, blockchain should not be used for that particular purpose. The guidelines also noted that if data is stored on-chain using certain commitment schemes where both the data and its key are deleted, the on-chain commitment may become meaningless enough to satisfy erasure requirements. I couldn’t find any indication that Sign Protocol implements or documents that approach.
I didn’t come across references to GDPR in the documentation, no discussion of the right to erasure, and no guidance on what a government deploying its identity infrastructure through Sign Protocol should do when a citizen requests that incorrect personal data be removed.
I find this gap more interesting than troubling, at least for now. The project's current government agreements are with Kyrgyzstan and Sierra Leone, neither of which falls under European data protection law. The Abu Dhabi partnership is still at the strategic positioning stage. So the tension between immutability and erasure rights has not yet collided with a real deployment. But the stated ambition is to serve sovereign nations broadly, which would eventually include EU member states.
The hybrid storage option is worth mentioning because it changes the picture slightly. Some attestations may not live directly on-chain. They’re stored on IPFS, a separate network.
The issue is, IPFS doesn’t promise permanent storage.
If no one continues to pin the data, it can disappear over time. When that happens, the attestation still shows up on-chain, but the actual content behind it is no longer retrievable.. The on-chain record would still carry a hash reference to what the data was, but the data itself would be gone. This creates a narrow path toward a form of de facto erasure. The documentation recommends against IPFS for reliability reasons and recommends Arweave instead, which is explicitly designed for permanent storage.
What I keep returning to is the asymmetry between who benefits from immutability and who bears the cost when something is wrong. Immutability benefits verifiers, institutions, and systems that want assurance that a record has not been tampered with after the fact. The cost of an incorrect but immutable record falls entirely on the person that record is about. That person cannot force the incorrect claim to disappear. They can only hope the issuer revokes it and that every system relying on the record checks the revocation flag and honors it.
The history of incorrect records in traditional systems suggests that corrections often reach fewer people than the original errors. Credit agencies that purchase data in bulk have been repeatedly found reinserting previously corrected items after updates. Background check companies that aggregate public records often lag months behind official expungements. The mechanism of correction exists but the propagation of the correction is uneven.
On a public blockchain, the propagation problem runs in the opposite direction. The incorrect record propagates instantly and completely to every node on every supported network. The correction, a new attestation linked back to the old one, requires every verifier to implement their own logic to find it, traverse the link, and prefer the corrected version. There is no standard for how that traversal should work. There is no enforcement.
I do not think this disqualifies Sign Protocol as a useful attestation layer. The problem of incorrect records is not unique to it, and for many use cases, the immutability is genuinely valuable. But if the protocol is going to be used for national identity systems where incorrect attestations could affect whether a citizen accesses healthcare, benefits, or legal status, then the question of what happens when the record is wrong may require a more complete answer than the current documentation seems to provide.
It might be worth asking whether the design philosophy of immutability was built for the use cases Sign Protocol started with, and whether the sovereign infrastructure ambitions require a different set of guarantees than the original architecture was designed to provide.