As a Builder, I want Dynamic on-chain SVGs for TransferableReceivable, so I can see parameters of the request when viewing on NFT marketplaces

[MantisClone]

Should we add dynamic on-chain SVGs to the TransferableReceivable such that key pieces of information like amount, approval state, balance, initial owner are rendered on-chain as part of the NFT image?

Background: Dynamic on-chain SVGs are rendered on-chain using on-chain information and then returned via the tokenURI function.

Example: Uniswap V3 positions.

Pros: The NFT image could display the current ReceivableInfo (tokenAddress, amount, balance, requestId). In the future, we may add the approval state as a public field on the NFT which could be dynamically rendered in an SVG.

Cons: On-chain SVGs drastically increase contract deployment costs

---

Migrated from Asana: https://app.asana.com/0/1203912381456855/1205300974037107/f

[MantisClone]

A challenge from @benjlevesque :

Why does the SVG generation need to be on-chain?

That's a fair question. For an asset that exists entirely on-chain like Uniswap V3 positions maybe there's a case for on-chain SVGs. But for an on-chain/off-chain asset like TransferableReceivables, we could build an off-chain service that renders the SVGs. Given that there are large portions of a request that already exist off-chain, putting SVG generation off-chain is not that big of a stretch. After this challenge, I lean toward an off-chain solution, if any.

[MantisClone]

Another challenge from @benjlevesque

why do we need an SVG? is it for compatibility with NFT UIs?

It's not compatibility per se. More for professionalism, trust, and quick recognition. The TransferableReceivable NFTs should display an image. even if it's a generic one that all of them share. This could give users more confidence that the token is authentic or legitimate. But it would be even better if the image displayed useful metrics about the request like the approval state, amount, balance, etc.