Canister status rollback

Hi, I have a question regarding the canister status.

Is it possible to rollback a canister status. Let’s imagine the following scenario.

  • I store a record in a canister.
  • I delete this stored record.
  • I rollback the status of this canister to get the deleted record back, similar the traditional approach to restore a record from a database backup.

If you trap during one of your update calls the canister will be restored to the state before the call happened (every await is also a commit point), but I think you’re not asking about this case.

Right now, you need to implement custom logic to do rollbacks. There’s some good ideas in this thread. AFAIK we intend to implement canister backup (downloading complete canister state) and restore operations soon™ but no concrete work has started yet.

1 Like

Thanks for your answer. My question is regarding the immutability of a blockchain and around the question: Goes the IC confirm with the GDPR.

Let me explain it with an example:
Imagine I have a user record stored on the IC. Later I would like to delete this record, I can do that easily with motoko and some logic.

But in this case the deleted record is not accessibe for me and others anymore. It remains saved in a previous state on the IC, but this state is not accessible for me. Is that correct?


ah, GDPR, that makes the context clearer. In general, subnets do not save the state for previous blocks except for some quite recent checkup points (think hours, not even days IIRC). So anything you delete should be lost to history pretty soon, however, it is not guaranteed to be thrown away (nodes could - for this case maliciously - store older backups).

If your application were to run on a public subnet, the whole answer would change, however. For more on that topic see this thread.


If I understand your point correct, the IC respects the GDPR right of forget, because the subnet will not store any previous state.

A malicious actor can make a copy without authorization but the same would be happen if a malicious employee from AWS or any other cloud provider could make a copy of my data.

But could you explain how this malicious actor can extract my data record in a human readable form from the copied state ?


Hey @rbole,

In general, see also this thread: GDPR compliant nodes and subnets

AFAIK the replica is like a black box for a node provider, but with some effort a node provider could dump the state of the replica and investigate it.
Technically, I’d argue it is way harder for a node provider to access data than for an AWS employee. However, AWS has signed the required contracts.


Yes, I believe that this is more legal than technical issue. But not less important. Actually legal aspect is more important for corporate customers.


Thanks for the link to the GDPR thread. After reading over this I ask myself, which kind of application can I build? So as a company based in the EU, we have to make sure the data remains into the EU. For some people is this the killer argument.

Also if the IC will replace the AWS, Google, Azure and co and will be a place for application developer I ask myself again as an entrepreneur which kind of application can we build and I don’t speak about any EU regulations like MiCA e.g.

I’m a little bit confused!! The tech is one side but If I can use the tech in legal secure way what’s then ?


Yes, absolutely. You cannot claim that you want to compete with AWS and ignore 99% of applications that require certain regulations. If Amazon or Google has to comply, they will have to ICP.
And it’s not just an EU issue. We had an interesting discussion with the guy from the healthcare space yesterday, he likes ICP. We could identify many potential highly valued applications, but you have to be HIPAA compliant, so data will not leave the US.
I think that ICP technology allows it to happen, just need to probably make some decisions.


I will give one example to be GDPR conform, hopefully.

Currently we are running an application which stores Verified Credentials (W3C) on the IC. The VC does not store personal data. In this point we are safe.

To verify or download such a VC we use a web2 application (frontend, and backend) hosted into the EU which works as a kind of proxy, a nodejs backend application does the final request to the IC canister, so the only IP which could be stored it’s ours and no customer IP address is stored on the boundary nodes of the node provider.

To answer my question: which kind of application you can build as an EU based company the following roles must be considered.

1.) encrypt all PII data
2.) use an backend Motoko or asset canister to store date, a frontend canister is not allowed (IP address of the customer could be stored outside of the EU)
3.) use a web2 application located in the EU as proxy to hide the customer IP.

I wonder why there isn’t more discussion about how these realities can be dealt with.


On ETH-Denver I heard about IC subnets.

My question is, is it possible to deploy my IC - Project to subnet located in the EU?

1 Like

I do not think that we have a subnet that’s only located in EU territory at the moment.

1 Like

Ok, so what can I say to someone issues that IP Adresse logged outside the EU and has fears about gdpr problems?


Hey Robert,

note that users access the IC via Boundary Nodes. The replica nodes won’t get the IP address of the user. Also, Boundary Nodes don’t log IP addresses AFAIK (cc @raymondk).

Furthermore, you could run your own HTTP Gateway (one part of a Boundary Node), and then even the DFINITY Boundary Nodes wouldn’t see the IP addresses of the users.