OpenSea image cache problem

[PaulRBerg]

I've just made the first borrow ever against a Sablier stream on NFTFI.

One problem I noticed is that the NFT image is sourced from OpenSea, which means that it is cached. This is a known issue that has been reported by Cantina during their latest audit of V2 Core.

This is a hairy problem for which the solution is necessarily multi-faceted. There are two practical ways to tackle it:

• Emit ERC-4906 metadata update events on cancel and on withdraw; this will keep the NFT platforms updated on the key milestones in the stream's evolution
  • This was already done in feat: integrate ERC-4906 #568
• Write a bot that pings the OpenSea API to update the SVGs for the most significant streams (e.g., active users or streams that are worth at least ~$100)
• Use this UI tool to manually refresh the metadata on OpenSea from time to time

[PaulRBerg]

Screenshot (the real streamed amount is something like ~820 USDC at the time of posting this):

[razgraf]

Should we remove the "live" data from the NFT?

In general (outside of edge cases):

• Streamed amount evolves fast
• Progress evolves fast-ish
• Status changes at certain points in time
• Duration is static

Streamed amount we could replace with total amount, as per #638.
Progress we can leave as is or approximate to milestones rather than exact amounts (e.g. <10%, <20%, ..., <90%, 100%).

---

Regarding the cached image, we could write a Github Action, triggered as a cron job once every 12/24h, that performs the metadata refresh. Wdyt?

[PaulRBerg]

I don't think we should remove live data. That's the most interesting aspect of V2 NFTs.

• Streamed amount evolves fast
• Progress evolves fast-ish

They both evolve equally as fast because the progress is generated from the streamed amount.

Streamed amount we could replace with total amount

We could but we don't need to get rid of the progress.

approximate to milestones rather than exact amounts (e.g. <10%, <20%, ..., <90%, 100%).

Two issues:

1. Implementing this chunk-based model would cost more gas than the current continuous-percentage implementation
2. The progress would still not be static in an absolute sense

Regarding the cached image, we could write a Github Action, triggered as a cron job once every 12/24h, that performs the metadata refresh

Great idea. This could be done for all streams for simplicity. In future versions we can optimize for only high-value streams.

[PaulRBerg]

I will create a GitHub Issue to track the implementation of the GitHub bot the next time we bump into this image caching issue.

[PaulRBerg]

Closing this as outdated since the problem has been solved, in part, by the ERC-4906 events that are now being emitted for all actions (cancel, withdraw, renounce, and transfer NFT).

Beyond this, it is not worth investing any additional effort. If the NFTs take off, we can consider writing a dedicated bot to refresh the SVGs on OpenSea.