Solutions needed as to making NFT's permanent

So as pointed out by Bob Bodily one of the NFT canister on ICP was not topped up and was removed/deleted. This points out an issue with a single point of failure regarding longterm storage of NFT’s on the IC. We are relying on teams and sometimes single individuals to top up canisters.

Ideally you want an NFT to last well forever. Devs will comes and go, people will leave projects and have health issues, or get hit by a bus. If this happens and canister are not toped up collections will get lost.

The knowledge that this could happen is likely to knock peoples confidence in purchasing an NFT.

One simple thing that could be done to help would be to have a seperate ledger of NFT ownerships.
In that way if a canister does go down we could use that to recreate the original collection.
Ideally though the actually images ( music video etc ) needs seperate backup also.

I personally store all my files on a few places in the event of needing to replace any images. Is there a way to have back up canisters that can store assets?

Even so someone at the moment has to pay for this storage. What happens in 10-20 or 50 years time?
Can we expect the same teams to be topping up these canisters?

Is there a way for the backup canisters to be maintained without needing top up from devs and individuals?

3 Likes

I have been raising this issue for a while, everyone just says that you as nft owner can just top up the canister and get the NFT. This solution is not a realistic thing to me, image the end user, he will even know what is a canister? It seems the team is not much concerned about this, and not doing much to support token standards, the nature of this reverse gas model has this major problem of putting the asset at risk due this single point of failure as you mentioned. I’m just starting to think if it is not ok, or if this is even is a problem compared with other NFT projects. I mean, the NFT is on chain forever on other blockchains, however, if the project fails, the value goes to zero, so do not matter if the NFT exists or not in the end of the day if the project do not survive. If the project survive, to team will keep supporting the canisters, also you can have a DAO to manage the canisters.

That make sense ?

3 Likes

I think the same issue is there on other blockchains, if the hosting site goes down or just decides to remove the content you are storing.
I get your point about the value being gone if the project does not survive, however old projects, games art, music etc can sometimes return and be popular many years after the original release.
Look at what happened to Kate Bush with her music on stranger things.

So I think we do need a better solution than random top ups.

I think this is a pretty solid suggestion from DGDG on twitter, but don’t know how practical/complex it would be to accomplish.

2 Likes

So we would have stages on canister decline. Maybe one stage before the end of the canisters life just before it gets deleted would be to send a ledger somewhere for safe keeping.

another solution would be to top-up the canister with such amount of cycles, that it will stay alive for decades - such move could be then advertised in the project description

1 Like

true, but it has cost implications as cycles should be cheeper if ICP goes up in value in the future.

cost of cycles is pegged with XDR, not with ICP, i.e. there is no correlation between cycles price and the price of ICP token:

The $USD cost for transactions below is based on the above cycle costs. 1 XDR is equal to 1 Trillion cycles. As of July 26, 2021, the exchange rate for 1 XDR = $1.42. The exchange rate for USD <> XDR may vary and it will impact the conversion rate. For XDR exchange rates please visit: https://www.imf.org/external/np/fin/data/rms_sdrv.aspx

– source wiki

The way I like to understand it is: XDR is being used as a stablecoin representing world’s economy, therefore, cycle’s price/value won’t oscillate that much. The exchange rate for ICP<>XDR is being continuously updated by NSS votes, see example.

Someone in the ICPMN group suggested this:

  1. Don’t add heartbeat to any canister with a registry. Uses too many cycles.
  2. We should separate registry/transfer from extensions into separate canisters or have plugin type system
  3. Freezing threshold should be higher for registry canisters ()
  4. Assets should always be on an asset canister rather than the NFT canister
  5. Assets and registry should be regularly backed up somewhere, or put assets in permanent storage (we don’t have this yet)

I agree with all points except 3 which I don’t see how it could be safely implemented on protocol level and I’d add what @mnl suggested:

top-up the canister with such amount of cycles, that it will stay alive for decades

Another mitigation would be to divide all assets in a separate canister so the owner of a particular NFT can top up the canister of the ones he personally owns. What do you think?
Dividing assets from ledger should be a must though, this way at least proof of ownership would be kept and services that integrate the NFT would still be able to give users their perks.

From my perspective the freezing_threshold is exactly what should save us from this issue. A developer sets the freezing_threshold in seconds and the IC translates that into a threshold in cycles given the idle consumption of the canister at a given time. The default value is 30 days. I agree that the best practice for NFT canisters should be a higher number, but I think the main issue right now is somewhere else.

Users (with their wallets and marketplaces etc.) typically only interact with the NFT canister via query calls, and currently the IC doesn’t reject query calls to a frozen canister. Only update calls and heartbeat etc. are rejected. This means the typical user doesn’t notice that the canister is frozen. Only when the canister is finally out of cycles and deallocated.

2 Likes

great points.

I think the ledger as a backup is a must. The ledger should connect id of the asset in asset canister, with the owner, with perhaps link to another backup of the asset in e.g. IPFS.

the

pay fee for the NFT you own

idea is something I both like and dislike - makes it even harder to own a thing (am I supposed to schedule reminders in my calendar to check if my JPG has enough food to survive the month?), but, it is kinda a good representation of the real problem - if I buy a historical painting, it will (one or another) incur storage cost on me. edit: but the more I think about it the more I like it

1 Like

am I supposed to schedule reminders in my calendar to check if my JPG has enough food to survive the month

Ideally this should never happen, NFT devs should copy Arweave approach and pay for 200 years worth of cycles to make sure the canister stays up for the foreeseable future, this can’t always be done though. If the NFT is hundreds of MBs or even GBs and the collection has many of them, the upfront cost would be prohibitive, especially if the collection doesn’t sell as expected.
In case the user has to take action or lose the on chain asset at least he’d be able to pay only for what he owns vs paying for everybody’s. Say I have an NFT which is about to run out of cycles and I’m the only one willing to pay for cycles, why should I pay to keep other’s people property online and get less uptime for the same amount of money as a result?

Another approach to be considered would be using TX fees to fund the NFT canisters, this would work only if the NFT is traded enough to cover the cycles expenses, which again depends on how heavy the files are.

1 Like

Is the usage cost variable according to how often NFT’s are accessed? How would we work out the costs ?

No, query calls don’t cost anything - see first table for complete breakdown of costs involved

1 Like

query calls don’t cost anything

This could change in the future, just like all the other prices so it’s hard to estimate what storage costs will look like in the years ahead.

2 Likes

Projects should just put enough cycles in their canister to last a year and perhaps design a way for a small portion of the royalty fee to go to the canister.

It would be nice to have a tool which allows you to lock some ICP for 8 years and instead of merging maturity, that ICP gets automatically converted to cycles with some frequency and sent to the canister to top it up.

Sure you would have to watch the price of ICP to make sure enough cycles are transferred but not too many in case of price appreciation (higher limit could be set automatically).

2 Likes

Hmmmm…you are forfeiting immense and unexplored power here. For our part, origyn is inextricably tying the assets and registry together so that the registry can compute over and manipulate the content according to a cryptographically secure smart contract. Separate canisters don’t necessarily prohibit this, but they make it more difficult. This becomes much more interesting when we move past monkey pictures.

Longer term we have on our road map a transfer tax that kicks in if the cycle count drops below a certain interval so that the market pays a flat percentage until the canister is all charged up again.

1 Like