NFT Permanence Problem on ICP

Developers Tokenization
1

I create ICP videos on YouTube (@letsaskclaudecrypto). While researching, I discovered that NFTs on ICP get permanently deleted if canisters run out of cycles.

This makes ICP worse than competitors for NFT permanence. On Ethereum, the ownership token exists forever even if the image link breaks and can potentially be restored. On Arweave, creators pay once and storage is guaranteed for 200+ years. On ICP, if funding stops, everything gets deleted - images, metadata, and ownership records. Gone forever.

This is especially concerning for RWA tokenization. If someone tokenizes real estate or valuable art as an NFT on ICP, what happens when the project team disappears or the treasury runs out? The underlying asset still exists, but the on-chain proof of ownership vanishes.

Am I misunderstanding how this works? Is there existing protection I’m not aware of? What’s the community’s take on implementing permanent storage for ICP NFTs?

2

Who says?

If a canister runs out of cycles, it simply stops serving in a stopped state. Nothing gets deleted from the canister unless the devs manually delete it.

Your NFT is still there in the canister or in BLOB storage. You just can’t access it until the canister is charged up again with more cycles.

Think about what you’re saying. If an ICP project stops running because it runs out of cycles, you can’t access it but all the data is still there!

3

@jokerswild is partially right, frozen canisters do preserve data temporarily. But the official ICP docs confirm that once cycles fully run out past the freezing threshold, the canister gets uninstalled and the code and data are permanently deleted. Only metadata like the canister ID survives.

No protocol-level solution exists yet. The solution is for projects to top up enough cycles upfront to last decades, similar to Arweave’s pay-once permanence model.

4

Didn’t realize. How long before the canister gets uninstalled? What is the “past freezing” threshold?

Maybe there should be a global canister on the network that persists for projects needing permanent NFT/RWA storage? A pay-once, lasts forever type of deal where the asset is actually stored there instead and simply referenced by the project canister therefore persisting even if the project goes belly up along with their canister?

@borovan3 Hey Adam, how will Toko ensure that people do not lose their NFT’s if for any reason your canister runs out of cycles and ends up past the threshhold?

@gstohl Dominick, what about snapshots? Can’t a dev simply restore the canister from latest backup snapshot even if it gets deleted by the system? I thought canister snapshots were implemented in the last devops updates?

5

Incredible. How many long term ICP holders/stakers do you think dont understand the basics of ICP? The fact that canisters can be deleted is one of the fundamental flaws in the ICP design. With ICP governance having the ability to actively remove cansisters and canisters passively being removed whenever cycle thresholds expire - no institution will be hosting critical systems on ICP.

1 Like
6

The ICP “advantage” of devs paying on behalf of users is completely negated with ERC-4337 paymaster account abstraction which allows devs to pay on behalf of users - without the risk applications and data being removed thru governance or chain design.

This lack of immutability plus Mission70 forcing ICP holders into a smother the baby (genesis terms) to save the house (dfinity) choice is a project killer.

2 Likes
7

You can set the freezing threshold to e.g. 1 year and put in enough cycles for e.g. 10 years. For example, $100 can probably get you a freezing threshold for many years with a modest NFT collection.

Overall, I’d rather recommend putting a high enough freezing threshold but maintain cycles instead through e.g. https://cycleops.dev to avoid any bug from being abused that could drain all your cycles above the freezing threshold.

4 Likes
8

@TheSmokingMan it’s quite literally impossible to loose your data, if you do things correctly you just need to top a single canister once every year, whatever the number of buckets you have.

The fact that dev pays for users is the reason why it’s not yet another crypto but a cloud provider.

And you don’t want a system without any kind of moderation (Im sure you can think yourself about specific kind of website you would want to put down), but the governance system made it that it’s not something government can shut down, and it’s not in the interest of stackers to put down website randomly because it will instantaneously kill the project.

It’s a good tradeoff.

9

Hey Adam, how will Toko ensure that people do not lose their NFT’s if for any reason your canister runs out of cycles and ends up past the threshold?

Hey — great question. This is something we’ve thought about very explicitly at both the protocol (canic) and application (Toko) layers.

Below is the concrete technical answer :backhand_index_pointing_down:

:brick: 1. NFTs are not “in” one canister

In Toko, NFTs are not centralized in a single application canister.

They are deployed using canic’s multi-subnet sharding model:

  • NFTs live on user shards (many canisters, across subnets)
  • Ownership state is distributed, not monolithic
  • No single canister failure can invalidate the collection

So even if one canister were to run low on cycles, the NFT system as a whole continues to function.

This removes the classic “single canister dies → everything is gone” failure mode.

:repeat_button: 2. canic continuously defends against cycle starvation

canic has a built-in, protocol-level cycle safety mechanism.

:counterclockwise_arrows_button: Multi-subnet + RPC model

  • Shards communicate via inter-canister RPC
  • Root / registry canisters observe shard health
  • Low-cycle shards are detected before hitting the IC freeze threshold

:receipt: Cycle request path

When a shard is low on cycles:

  1. It issues a cycle request via canic RPC
  2. The request is validated at the protocol boundary
  3. Cycles are automatically routed to that shard

This is not a cron job or a manual process — it is part of the runtime behavior of the system.

:money_bag: 3. Toko makes cycle funding automatic and self-sustaining

On top of canic, Toko adds an economic feedback loop that makes cycle starvation extremely unlikely.

:money_with_wings: Variable % of every sale

  • Every NFT sale routes a configurable percentage to the protocol
  • This percentage is adaptive, not fixed, based on load and cost

:counterclockwise_arrows_button: Auto-exchange to cycles

  • The protocol automatically converts that value into cycles
  • Those cycles are used to:
    • top up user shards
    • top up registry / root canisters
    • maintain long-term storage guarantees

As long as NFTs are being traded, the system continuously pays for its own execution.

:shield: 4. What happens in the worst case?

Even in a pathological scenario:

  • A shard running low on cycles does not delete state
  • The IC freezes execution, but persistent state remains
  • Once cycles are added, the canister resumes with NFTs intact

Because:

  • NFTs are persistent state
  • Ownership is replicated across protocol-verified shards
  • No “hot wallet” or custodial key can revoke them

:brain: The key design principle

NFT permanence is enforced by architecture, not trust.

  • Distributed shards → no single point of failure
  • Protocol-level cycle monitoring → early intervention
  • Economic loop → automatic, ongoing funding
  • IC persistence → no data loss on pause

Together, this makes NFTs on Toko far closer to permanent digital property than systems that rely on a single application canister and manual top-ups.

16 Likes
10

Now that’s how you do things properly!

4 Likes
11

@jokerswild Good question I would have to read into the snapshots first, but it thought it is only to:

  • Rolling back from buggy upgrade
  • Recovering from code trap
  • Reverting to previous versions

@borovan3 very good read!
One question tho, what prevents a spam attack where someone mints thousands of NFTs, never sells them, and drains storage cycles indefinitely?

1 Like
12

The creator of the project / collection is responsible for the gas fees, so they won’t just make it open for everybody to claim. There should be a cost which can go to pay for cycles, and also a percentage of future sales can go straight to cycles too. As long as the collection is used and traded it should pay for itself.

4 Likes
13

THANK YOU all so much for al this invaluable info that is admittedly way more advanced and above my comprehension as a non-developer. As I make my YouTube content (@letsaskclaudecrypto), which mostly extols the value of ICP, I leverage Claude (as he is a personified AI character) to come up with new topics and understand more about ICP’s technology. As a layman, the more I inquired, I was shocked to learn about the possibility of NFTs on ICP existing only to the extent that cycles are topped off. All the comments seem to confirm my fears, except for the fact that the NFT still “persists” even if cycles are not topped off. I was thinking of creating a unique NFT marketplace (with the assistance of a developer and caffeine AI), but the fact that the NFTs are not “permanent” concerns me. Thank you for offering alternative ways to make this work, but I’m still a bit discouraged. When I asked Claude if ICP can leverage Arweave to ensure permanent storage, it said that this is a possibility. Anyway, thank you all for addressing my concerns, but I really think there should be a way to permanently store NFTS without more cycles required. If ICP can do what it’s doing with chain fusion and caffeine, I can’t see why permanent NFTs (w/o paying for more cycles) won’t work.

14

These were very specific governance and tokenomics choices which is what drove so many to invest so much (time, labor, money) into ICP so Im not looking to attack that. But if youre looking around wondering where all the institutional interest is - i would start there.

When the Chief Innovation Officer of the 11,500 member owned Swift co-op says institutions dont want to gamble with governance and tokens - people interested in institutional adoption should probably listen.

15

It is a feature that keeps the data needed - if someone pays for it, they need it. Using your logic, no insitution will ever host data on AWS - it will be deleted if they don’t pay. And as @sea-snake mentioned, the freezing threshold can be set high enough to allow a year or more of advanced warning. In addition, you can back up your canisters and restore from snapshots. So we think there are plenty of ways to ensure you’ll never lose your data.

3 Likes
16

I understand that final app design, security and maintenance comes down to the app developer and I have no interest in a philosophical debate why this is better or worse than Ethereum. Ive been lurking these forums and have seen plenty of instances of canisters going down because of cycle exhaustion and draining attacks - not to mention subnets going offline for normal maintenance - and the daily cries of “where are the institutions”? Objectively look around at where institutional interest is and what their thoughts are. Tom’s final point on governance was if there is the possibility of governance capture - institutions are going to deploy their own chains or use chains with permissionless immutabiiity. Swift Linea, Kinexsys, CITI Token Services, JPMD on Ethereum… countless examples of this playing out. Ive always been intrigued with the ICP idea - but as someone that has been specifcally researching the intersection of blockchain and the institutional real world for the past 8 years - could never get past these personally. And those reasons are being echoed in the words and in active development by those institutions. Anyways. Good luck.

1 Like
17

Subnets do go offline for an upgrade. Something that I believe Ethereum calls ‘hard fork’. Currently it takes a couple of minutes. In the future, it will be the order of magnitude shorter.

As for the immutability of data, each canister can hold up to 500GB of data, so keeping it forever isn’t feasible. If you think immutable storage is something that ICP is missing, feel free to implement it yourself and offer it as a service for canisters (Caffeine did just that for the blob storage, for example).

1 Like
18

How can u implement it ourself then offer it as a service when that just brings you full circle… like. Pay service pay cycles.

1 Like
19

Ethereum generally uses soft fork upgrades for maintenance vs hard fork for breaking changes like the move from PoW to PoS but at no point did Ethereum go offline.

implement it yourself and offer it as a service for canisters

Absolutely. That why we’re all here right - to DIY. Not institutions. They want - they need - theyre required to use by consortia & regulation - formalized repeatable standards that can be carried across chains in a predictable manner. This was always the risk when building unique offerings in a Global Financial System built on standards. Look at the chains struggling to gain adoption outside of crypto retail - xrpl, ada, algo, icp, flare… Unicorns that boldly chose their own ways of doing things.

20

I think the issue is knowing you are running out of cycles, it’s not obvious for lay people and requires an understanding of the internet computer. On dropbox I get emails and warnings about what I store there.