Credits: what survives when 80 NFTs become one?

An ordinary payment becomes a source material

Credits begins with a small transaction. The project’s official description associates an eligible $8 X Money payment with a Credit. Its transaction ID is hashed with SHA-256, and bits from the result define four 8 × 8 grids for cyan, magenta, yellow, and black. The payment timestamp determines which layers appear. A record produced for one purpose becomes material for a visual composition.

The project also describes assembling 80 Credits into a Statement. That changes the unit through which a participant encounters the work: separate pieces are brought into a larger composition. It also gives a technical reader a concrete question. After assembly, what does the participant own, and what has happened to the inputs?

The original allocation page lists 122,154 Credits, enough for at most 1,526 complete groups of 80, with 74 remaining. This is an arithmetic ceiling based on that allocation, not a current supply figure, an estimate of participation, or a statement of market value. As checked on September 27, 2026, the official project page scheduled Statement assembly for October 1 at 8 p.m. ET.

A technical walkthrough on LearnBlockchain uses this concept to explain NFT assembly. The example lets us follow an ownership transition step by step. Its sample Solidity contract is educational material, not evidence that the artist’s production contracts implement the same process. Keeping that boundary clear makes it possible to learn from the example without attributing its choices to the artwork.

Reproducible art still needs a delivery process

The image recipe and the delivery of a token answer different questions. Given the specified inputs, a deterministic process can recreate the visual result. It cannot decide on its own whether a payment was eligible, which wallet should receive the token, or whether delivery succeeded. Those responsibilities exist around the recipe.

For a builder designing a similar system, the boundaries are worth drawing explicitly. A payment service supplies a receipt. An application checks eligibility and associates a wallet. A contract records token ownership. A duplicate receipt, an incorrect wallet association, and a failed mint are different kinds of failure, even if a user encounters all of them through the same screen.

This distinction also locates the limit of rollback. A reverted onchain transaction can undo changes within that transaction. It cannot reverse an earlier payment completed through another system. A participant needs a coherent experience across those steps, so the product must explain or recover from the places where one part succeeds and another does not.

Custody leaves the original objects in existence

In the walkthrough’s assembly loop, the contract checks each input’s owner and calls transferFrom to move the NFT into the assembler contract. The result is custody: the source tokens still exist, with the assembler recorded as their owner. Whether they can leave later depends on the methods and upgrade powers available in that contract. Describing the transfer as a burn would hide that continuing ownership.

A true burn follows a different path in the source NFT contract. In OpenZeppelin 5.4.0, transferFrom rejects the zero address as a recipient. The internal _update function supports minting, transfers, and burns, and _burn uses that burning path. An external assembler cannot simply invoke another contract’s internal _burn. The source contract needs to expose an authorized mechanism for destroying the token, such as a suitable burn function.

The distinction is useful well beyond vocabulary. An indexer can still find a token held in custody. A later integration may need to know whether it exists and which contract controls it. Participants may want to understand whether assembly is reversible, whether an operator has a recovery power, or whether the originals are permanently beyond their control. The ownership transition establishes the beginning of those answers.

The diagram shows the educational custody route. It separates the contribution of the inputs from the minting of the output, then contrasts custody with a real burn. The visible artistic result may be one new work; the complete token history can contain more than that single result.

The last handoff is still part of the transaction

The example performs its checks, input transfers, counter update, and output mint within one transaction. If a transfer or receiver check fails and that failure propagates out of the transaction, the earlier state changes in that transaction revert as well. The input collection should not remain partly transferred while the output fails to arrive. Code that catches an error can change this behavior, which is why the full call path matters.

Minting safely introduces a further handoff. OpenZeppelin’s _safeMint can call onERC721Received when the recipient is a contract. That gives external code an opportunity to execute before the original transaction finishes. The receiver may reject the NFT or attempt another call into the assembler. The word “safe” describes a receiver-compatibility check; it does not establish that every possible interaction with the receiver is harmless.

Relevant accounting should therefore be settled before control is handed outward, and every reachable entry point needs review. ReentrancyGuard can protect guarded functions, but the surrounding design still determines which states an external callback can observe and which other paths it can reach. This is where the apparently simple gesture of many objects becoming one becomes a transaction with several participants.

Test the promise a participant thinks they accepted

The most valuable tests describe what must remain true when assembly fails. A batch of 79 or 81 inputs should not behave like a valid group. A repeated ID, an NFT belonging to someone else, a missing approval, or a reached supply cap should leave a result consistent with the intended rules. Successful minting is only one path through the mechanism.

Contract recipients make the test more revealing. One receiver can reject the output; another can attempt to reenter during its callback. When the failure propagates, the test should verify that neither collection has been left in a partial state. A counter that looks correct is insufficient if some inputs moved, or if an external path was able to act on accounting that had not yet been finalized.

The final assertions must match the promised lifecycle. For custody, the assembler should own the contributed tokens. For a genuine burn, those source tokens should no longer exist. Compiler, library, and EVM versions should be pinned to the deployment being tested, so the implementation under examination is the one a participant will actually use.

These checks turn a phrase such as “assemble 80 into one” into an inspectable agreement. They identify what the participant contributes, what they receive, and what should happen if the exchange cannot finish. That agreement is part of the work’s experience, even when it is expressed in code rather than on the canvas.