Bitcoin Ordinals: SVG vs SVGZ When creating art specifically to store on-chain, I prefer to create vector art. While I love the aesthetic of dither masters like @0xdiid, there is something very satisfying about the pixel-perfect crispness of a vector image that will not pixelate despite being resized. This is why every piece that I have put on-chain (both on Ethereum and Bitcoin) has been an SVG. This weekend, I had a thought about SVGs and #Bitcoin #Ordinals. I was working with an SVG piece that, even after I had simplified the piece significantly, was coming in over 100 KB. If I compressed the SVG by using the SVGZ format (essentially a GZIP'ed version of an SVG), the file size was reduced to around 30 KB. Modern web servers can serve SVGZ files just as easily as uncompressed SVGs (almost - I'm trying to stay out of the technical weeds with this initial post). I inscribed a test image over the weekend. However, the SVGZ isn't viewable on @ord_io, @trygamma, @MagicEden, or Instead, you get a standard error. It appears that the sites are handling the SVGZ as a standard SVG and not decompressing the data properly (this is not uncommon since SVG and SVGZ share the same MIME type). Here is my question and proposal. If we made it so that SVGZ inscriptions could be viewed more easily, it would reduce the size of the inscription by a very large amount (more than half). I can think of two solutions: 1) Use a JS library (like pako) to decompress the SVGZ (essentially, you still wouldn't be able to see the base inscription, but you would be able to see the recursive editions as if they were standard SVGs). I haven't gone too far down this rabbit hole, but it's an interesting idea that could save artists a lot of money over the long term. 2) Have major Ordinals sites and marketplaces display SVGZ files correctly. I think this is the simpler option, technically, but might be harder from a coordination standpoint. I would love to hear what other people think. 🙏

Next week. 🟩