Currently, the chain logos must be SVG files because the tooling expects to find them at a specific location: chains/${CHAINNAME}/logo.svg.
Instead of assuming that specific path, we could check the logoURI field in the chainMetadata.yaml file. If it's relative, assume it's a path inside the registry and grab the image from there. This is essentially what the tooling already does for logo URIs in warp route config so the work here is mostly to normalize our handling of logos.
_Note: even though URLs in logoURI fields are currently allowed, the CSP header in the Warp UI will forbid the loading of assets from arbitrary URLs`
Currently, the chain logos must be SVG files because the tooling expects to find them at a specific location:
chains/${CHAINNAME}/logo.svg.Instead of assuming that specific path, we could check the
logoURIfield in the chainMetadata.yaml file. If it's relative, assume it's a path inside the registry and grab the image from there. This is essentially what the tooling already does for logo URIs in warp route config so the work here is mostly to normalize our handling of logos._Note: even though URLs in logoURI fields are currently allowed, the CSP header in the Warp UI will forbid the loading of assets from arbitrary URLs`