Implemented now
- Four deterministic SVG organisms.
- Simulated keeper changes and mutations.
- Seal confirmation and fixed art after sealing.
- History inspection and SVG plate downloads.
- Browser-local persistence and per-specimen reset.
Ownership as a visible trace.
AFTERIMAGE is an independent generative-art experiment. Ink organisms carry the idea of passage: an artwork changes as it moves between keepers, until a keeper chooses to seal its current appearance.
The intended NFT concept makes transfer history part of an evolving artwork. The website currently demonstrates that idea in your browser. It does not connect a wallet, mint a token, send transactions, or record anything on a blockchain.
Read this first
The four studies are non-mintable demo artwork. A downloaded image is not an NFT, a numbered keeper is not a verified person, and a local history is not proof of ownership.
A short field exercise.
- Open the specimen room and select one of the four studies.
- Choose Simulate a transfer. The keeper number advances and, while unsealed, the art mutates.
- Move the ownership-trace slider to revisit an earlier state. This is a view into history, not an undo.
- Choose Seal this specimen. Review the latest artwork in the confirmation dialog, then confirm or cancel.
- Transfer the sealed specimen again: ownership advances, but the image stays the same.
- Choose Download plate to save the state you are viewing, or Start a new demo to reset this specimen.
No wallet, ETH, or account is needed. The mint control is intentionally disabled.
Anatomy before accessories.
Each study has a distinct construction, not merely a different outfit or color. These four organisms are samples only, not the full production collection or a rarity system. The planned collection has a fixed total supply of exactly 5,000 NFTs; the contract is not yet deployed.
Art acceptance requirement: every production NFT must be visibly distinct through silhouette, anatomy, or major structural traits—not merely its ID, name, or color. The origin archive now contains 5,000 generated SVG artworks, PNG previews and metadata, across twenty organism families. The versioned renderer and seed manifest reproduce the same origin in browser and export. All 5,000 decoded foregrounds and every pair of 32×32 ink-occupancy thumbnails have been screened; audit results and limitations and closest pairs are public. Automated screening is not aesthetic approval or proof that every pair is visibly distinct. Full independent human visual acceptance remains outstanding. No tokens are minted; no contract is deployed. The original four studies below are preserved separately. The collection browser adds per-token transfer, history and seal simulations in memory only, reset on reload.
- 001 / CERVID FORMThe Witness
- A tall, antler-crowned organism with exposed ribs and long legs. Its branching crown carries the language of memory.
- 002 / SPIRAL FORMThe Pilgrim
- A wandering, shell-bearing organism: a weathered spiral cathedral balanced on small walking limbs.
- 003 / PELAGIC FORMThe Undertow
- A deep-water bell with a watchful eye and long, branching filaments that suggest the pull of passing tides.
- 004 / FOSSIL FORMThe Relic
- A fossil-wing organism whose delicate ribs and wing structure preserve the residue of flight.
The same state, the same drawing.
The demo renders original vector artwork as SVG using a seeded JavaScript drawing engine. Its inputs are the organism type and mutation generation. With the same renderer and inputs, it reconstructs the same SVG; it does not request an image from a remote generator.
A stable base seed defines the anatomy. A generation-dependent seed drives mutation marks. Returning to an earlier generation reconstructs that plate rather than fetching a stored screenshot.
This is deterministic rendering, not cryptographically secure randomness. Demo traits are not derived from wallet addresses. The four fixed studies do not establish rarity, economic value, or uniqueness across a future collection. Renderer changes could change output; no immutable onchain renderer has been deployed.
Passage changes the plate.
A simulated transfer appends a history entry and advances the numbered keeper. For an unsealed specimen, it also advances the mutation generation. The drawing expresses this as seeded scars and traces while retaining its underlying organism.
In the proposed production design, qualifying canonical token transfers must drive deterministic visual changes from the token's recorded state, rather than arbitrary frontend rerolls. Sealed tokens retain a fixed appearance through later transfers. The exact contract rules and production renderer remain future work. Testing the 5,000 origin artworks will not prove uniqueness across all conceivable future mutation states: those states need separately defined collision and visual-similarity tests, and no universal uniqueness guarantee is made.
The counters measure different things: Simulated transfers counts passages; Art mutations counts visual generations. After sealing, the first can keep increasing while the second stays fixed.
Actions always apply to the latest state, even when you are viewing an older trace. The history slider cannot branch the specimen's history or transfer a past version.
A transfer is not a unique person
Keeper labels are simulated identifiers. Even a real token transfer would not prove that a new human owns it: one person can control several addresses, and self-transfers may occur. Future contract rules for qualifying transfers have not been finalized.
Freeze the artwork.
Not the ownership.
Sealing fixes the latest visual generation for the selected specimen. It does not prevent later transfers. New keeper entries can still appear in the demo history, but the sealed image no longer mutates.
The confirmation dialog previews the latest artwork, not an older plate selected on the slider. Canceling leaves the specimen unsealed. Confirming disables the seal control for that simulation.
There is no unseal action within the demo. Start a new demo discards that specimen's local simulation and creates a fresh one; it does not reverse an onchain event.
Permanent sealing is a proposed contract mechanic, not a deployed guarantee. Any future permanence claim must be assessed against the actual contract, renderer, metadata storage, upgrade permissions, and network assumptions. A frontend label alone cannot make art immutable.
Revisit a trace. Keep a plate.
The ownership-trace slider runs from origin to the latest simulated transfer. It shows the keeper and event for that position and reconstructs the corresponding artwork. Your live counters continue to describe the latest state.
Download plate exports the currently displayed artwork as an SVG, including an earlier historical state if that is what you have selected. The filename identifies the study and mutation generation and marks the file as a demo.
The download is a single artwork, not a full history export, ownership certificate, or minted token. There is currently no built-in JSON history download. Save any plates you want before resetting the specimen or clearing browser storage.
A local notebook, not a ledger.
- 100 transfers per specimen: origin plus up to 100 transfer entries. The cap includes transfers after sealing. At the limit, transfer is disabled; downloading and resetting remain available.
- Local persistence: the four specimen states are saved to this browser's localStorage when available. Refreshing normally restores them. They do not sync between devices, browsers, or website origins.
- Storage can disappear: clearing site data, private browsing restrictions, unavailable storage, or invalid saved data can prevent restoration. There is no server backup or recovery service.
- Reset is specimen-specific: “Start a new demo” resets only the selected specimen's keeper, mutations, seal, and history. The other three studies are left alone.
- Not tamper-resistant: local browser data can be edited or deleted. It must not be treated as an authoritative ownership record.
The cap is a demo safeguard, not an announced onchain transfer limit. Resetting has no financial or blockchain effect.
What exists. What does not.
Proposed, not deployed
- An NFT contract and real token ownership.
- Transfer-driven onchain state changes.
- Contract-enforced sealing by an authorized owner.
- Production metadata and renderer architecture.
- Minting, marketplace integration, and wallet flows.
The intended direction is an evolving collectible whose visual state follows its token history. The demo validates an interaction, not the security, gas costs, storage model, or permanence of an eventual implementation. No audit or production-readiness claim is being made.
A target, not a deployment.
The project's intended network target is Robinhood Chain mainnet, chain ID 4663. This names a design target only: AFTERIMAGE has no deployed contract and the demo does not use an RPC connection.
- AFTERIMAGE contract
- Not deployed / no address
- Mint price
- Not set
- Planned fixed total supply
- Exactly 5,000 NFTs / contract not yet deployed
- Mint date
- Not announced
- Wallet & payment
- Not enabled
These are AFTERIMAGE's own project docs. Network specifications are separate from project mechanics. For network configuration only, consult the Robinhood Chain connection guide ↗ (external secondary source; not AFTERIMAGE documentation).
AFTERIMAGE is independent and is not affiliated with or endorsed by Robinhood. Do not send funds to an address claiming to be this demo's mint.
Before you leave a mark.
Can I mint or buy one now?
No. The site is a non-mintable experiment. The planned fixed total supply is exactly 5,000 NFTs, but there is no deployed contract address, announced price, or enabled payment flow.
Does sealing make it soulbound?
No. Sealing fixes the artwork, not ownership. The demo permits transfers after sealing, up to its local transfer limit.
Can I seal an earlier historical drawing?
No. The slider is for inspection. The seal dialog always previews and seals the latest artwork.
Is my history public or permanently stored?
No. It is local browser data, not a public ledger. It can be lost, reset, or edited, and no server backup is provided.
Why does a sealed transfer look unchanged?
That is the intended distinction: a new keeper without a new mutation. The transfer counter advances; the art-mutation counter does not.