80 NFTs in. One out. What did the contract really do?

A payment receipt becomes a creative seed

Jack Butcher’s Credits connects an ordinary payment to generative art. The project’s official description associates each eligible $8 X Money payment with a Credit. Its transaction ID is hashed with SHA-256; the resulting bits define four 8 × 8 grids for cyan, magenta, yellow, and black. The payment timestamp determines which layers appear.

The project also describes combining 80 Credits into one Statement. Its original allocation lists 122,154 Credits: enough for at most 1,526 complete groups, with 74 left over. That arithmetic describes a ceiling, not participation or value. As of September 27, the official page schedules Statement assembly for October 1 at 8 p.m. ET.

A Chinese technical walkthrough uses this idea to teach NFT assembly. We will examine the mechanics of that educational example. Its sample Solidity contract is not evidence of how the artist’s deployed contracts work.

Deterministic art does not remove the delivery step

A reproducible image recipe answers one question: what artwork follows from these inputs? It does not establish whether a payment qualifies, which wallet should receive the NFT, or whether delivery happened. Those remain separate operational responsibilities.

For a builder, draw that boundary before writing the minting function. A payment service can supply a receipt; an application can verify eligibility and associate a wallet; a contract can record ownership. Duplicate receipts, incorrect wallet associations, and failed deliveries each need their own handling. An onchain revert cannot undo an earlier payment through a different system.

A locked token still has an owner

The walkthrough’s assembly loop checks each input’s owner and calls transferFrom to move it into the assembler contract. Those tokens remain ERC-721 tokens, now owned by the assembler. Whether they can ever leave depends on that contract’s available methods and upgrade powers. A transfer into custody is not a burn.

OpenZeppelin 5’s transferFrom rejects a zero-address recipient. Its internal _update function supports minting, transfer, and burning; _burn uses the burning path. A separate assembler cannot simply call another contract’s internal _burn. The original NFT contract must expose an authorized mechanism, such as an appropriate burn function, if destruction is the intended behavior.

This distinction matters for supply reporting and future integrations. A marketplace, indexer, or lending protocol may treat an existing token differently from one whose ownership has been destroyed. Explain the actual lifecycle before describing the mechanism as deflationary.

Make the whole operation succeed—or roll back

In the sample, one transaction checks the required quantity and supply cap, transfers the inputs, updates the counter, and mints the result. If a transfer or receiver check fails and that failure propagates out of the transaction, earlier state changes in that transaction revert too. Error-catching code can change that behavior, so inspect the complete call path.

The last step still deserves attention. _safeMint can call onERC721Received on a contract recipient, giving external code control before the transaction finishes. Update the relevant accounting before that handoff and review every reachable entry point. ReentrancyGuard helps protect guarded functions; the word ‘safe’ in _safeMint does not make arbitrary callback interactions harmless.

The useful tests are the inconvenient ones

A successful 80-to-1 example proves very little about failure behavior. Build a test matrix around ownership and accounting invariants, then verify that rejected operations leave both collections unchanged. Include contract recipients rather than testing only ordinary wallets.

• Try 79 and 81 inputs, repeated token IDs, and a batch containing someone else’s token.
• Remove an approval or reach the supply cap; verify no partial transfer survives a revert.
• Use a receiver that rejects the NFT and one that attempts to reenter during its callback.
• For custody, assert the assembler owns every input. For a true burn, assert the input tokens no longer exist.

Let the implementation finish the story

The art makes the mechanism memorable. The engineering work is to turn its promise into explicit rules: who can contribute, what happens to each input, how the output is counted, and where control can escape. Pin the compiler and library versions you test, and choose an EVM target supported by your deployment chain.

When the next project promises to turn many things into one, start with ownership. Then trace the callbacks and the rollback boundary. Those three observations reveal more than a dramatic name ever will.