jameswenzel / bound-layerable

Smart contract template for binding and layering tokens

BoundLayerable

BoundLayerable is a set of smart contracts for minting and then composing layerable NFTs on-chain.

The BoundLayerable flow:

• A user mints a set of N "layers" efficiently using ERC721A
  • The first is a "base" or "bindable" layer
• Layers are revealed on-chain
• Users can burn a layer to "bind" it to their base layer
• Users can update the base layer's metadata on-chain to show/hide and reorder layers

Technical specs

• Secure on-chain randomness using ChainLink VRF
• 8 types of layers
  • Up to 32 unique layers per "type" elements, except the 8th type, which supports 31 unique layers
  • 255 total unique layers
  • 16-bit granularity (~0.0015%) for trait rarity
• Up to 32 "Active" layers at once
• Traits and metadata stored on-chain
• Updateable metadata contract

bound-layerable's Issues

Add batteries-included SVGLayerable Implementation

Add PREVRANDAO alternative to Chainlink VRF on Ethereum

Post-merge, PREVRANDAO is an acceptable source of randomness, and would simplify the randomness process.

Constructor of a PREVRANDAO-based source of randomness should revert if chain associated with block.chainid does not have the PREVRANDAO opcode (ie, is not 1)

Remove Slither from CI

shit don't even work

add _isBaseLayer virtual method for overriding base layer logic

Currently hard-coded to check for tokenId % NUM_LAYERS_PER_SET == 0, which prevents setting custom starting token ID, etc

Avoid Modulo Bias with dedicated PRNG

See https://github.com/Vectorized/solady/blob/68699019a4cfaaa22ef1e612bac085fc3ba508f6/src/utils/LibPRNG.sol

Reproduce in local?

Thank you for the wonderful repo!
Layered NFTs feel so unexplored yet soooo interesting, this is crazy. Appreciate sharing your knowledge - I tried reproducing it on my local computer with hot-chain-svg, it didn't produce an output.

Feel free to destroy this if repo is wip

[Metadata Contract] Use per-trait random seed to affect trait expression

Add distributions for trait expressions
Allows for different traits with the same layerId

depends on #9

Support multiple traits per layer

Change Attribute mapping to Attribute[]. See unfinished MultiOnChainTraits.sol

Explore binary search for layerId lookup in distributions

Currently checks each packed distribution in-order, meaning it will perform 32 checks in the worst case.

Binary search, starting at index 15 (end of first packed distribution array) would performs ~6? checks in worst case

Use deploy block difficulty/blockhash as a secondary immutable component of randomness

Hash along with batch randomness seed so each contract will produce totally different results for a given tokenId, layerType, batchSeed

Investigate traits with random numeric components

Ie "stats" layers - "Strength" and score out of 10 or 100

Can use to influence overall stats (cumulative) or per-trait

Explore packing layerId into ERC721A _extraData

We should always store layerId for base tokens upon binding, since they may be re-bound or rearranged, and the extra 100-200 gas to read the extraData from warm ownership slot is going to be cheaper than the layer seed calculation + lookup.

Since layer tokens are burned upon being bound, they should not store their layerId during the binding process.

It may be worth looking into calculating+storing the layerId for any token when transferring. The ownership/extraData storage slot will already be warm, but calculating will add at least 5000 gas on first transfer after reveal in worst cases (max 2 SLOADs for packed distributions, plus all comparison and calculation overhead - unsure on specific gas usage).

Minimizing gas usage during binding+arranging for end-user experience may be worth the added gas overhead during transfer - but a better gas analysis should be done.