Work Requirements

Types of work

We saw generative art as the obvious starting point for Singular given how it's long since been the on-chain standard over the years, yet standard approaches up to this point have still come with off-chain dependencies and tradeoffs. However, the Bitcoin blockchain and the Ordinals protocol affords us the ability to inscribe any file type and format directly on-chain in its entirety. This includes generative scripts (usually .JS), .HTML, .GIF, .MP4, .PNG, and all other file types.

So while projects we've released thus far or supported in the past were all generative works and we plan to continue keep supporting generative releases for the foreseeable future, we look forward to supporting a wide range formats and niches. We welcome any and all artists, generative or not, looking to further explore the Bitcoin and Ordinals ecosystem to reach out.

Project Size

For most purposes, individual inscriptions generally can be up to 400kb in size. However, much like other chains, costs to put data on-chain go up the larger the size of said data. And with that, using recursion means final outputs can be comprised of data that is far greater than 400kb in size if required by a project.

Generative artists should aim to keep their scripts (.JS) under 20kb in size. However, that is a soft suggestion rather than a hard requirement and comes down to a project-by-project basis.

Compression

Artists can deliver their work either compressed/minified or uncompressed/unminified. Our team will ensure the work is compressed and optimized to be ready to be put on-chain.

Ordinals can utilize native brotli compression which can aid in drastically bringing down the size of certain types of data being put on-chain. We use this compression where applicable.

Seeding Method

On other chains, the prevailing method for adding sources of entropy to work is using the transaction ID (TXID) and, to a lesser extent, the token ID/number. On Singular, artists have the choice of selecting what seeding method bets fits their work and as many as they would like.

This can include:

• TXID

• Inscription ID

• Name/ID of the sat being inscribed on

• Any of the native recursive endpoints (using data from existing inscriptions, blockinfo, blockhash, blockheight, etc.)

Our mantra is firmly "if the data can be accessed, we can support it." If you have an idea for a new seeding method, let us know!

Libraries

Generative artists on Singular can use as many (or as few) libraries as they desire. Though Singular can and has inscribed project-specific libraries, we urge artists to review what libraries are already on-chain here.

Libraries can easily be integrated into works using a relative link and the inscription ID. If your work uses p5.js, you would include an inscription ID pointer to one of the on-chain p5.js version like so:

<script src="content/b6a50f5ba932b0ea7f652d9d28e59eced47bc6f8376c25e02d8b3457bb60ac8fi0"></script>

While testing, you can include an appendage to the library link using https://ordinals.com/ but it should be removed prior to inscription.

Our engine will doublecheck that libraries are referenced properly prior to inscription. Our team will also handle the implementation of recursive libraries if an artist is unsure about how to do it properly.

Metadata

Ordinals support a form of native on-chain CBOR metadata. This data is human-readable and is rendered in the output inscription in HTML. For example:

• Inscribing traits with a work would take the form of {"foo":"bar","baz":[null,true,false,0]} asd

• The output inscription would contain a block in the HTML like so:

  

Another option for artists is ASCII-based art, though this is not recognized by the protocol. An example of this is: