AB[500] Series Essays

Version: 1.0.0
Date: 2026-09-06
Program status: Draft, not open
Coverage: One original essay for each of the 500 AB[500] series
Delivery surfaces: AB5D website, iOS, and Android

1. Purpose

Write a lasting reference account of each series: what it is, how it was conceived and constructed, what happened during its mint, and which rights apply. Address interested collectors and readers without assuming programming knowledge. Explain technical terms through their visible effect on the work.

Each essay must be 1,500–2,500 words, excluding bibliography, captions, and research notes. Inspect available source code. Executing or reproducing the original work is optional and must never be implied when only inspection occurred.

This program adds series-specific research to the existing artist dossiers. It must not simply repackage the artist biography. The canonical roster is data/atlas.json, joined to the contract identities in data/ab500-contracts.json.

This document specifies future submissions and includes a reusable assignment template. It does not open offers, promise payment, commission the essays, or implement a validator, renderer, API, or app release. Those are subsequent work with the launch gates in section 9.

2. Required essay content

Use the following seven section IDs in order. Headings may be adapted to the series, but each section's required coverage must remain identifiable.

2.1 The work and its context (work-context)

Identify the series, artist or collaborators, Art Blocks category, and release period. Explain its central idea, visual character, and place in the artist's practice. Keep biography brief and link to the relevant existing AB5D artist dossier or dossiers. Preserve original collaborative credits.

2.2 Conception and development (conception)

Describe documented origins, influences, experiments, development timeline, and artistic decisions. Attribute statements of intention to their sources. Distinguish the artist's account from the agent's interpretation. Do not turn visual resemblance into an asserted influence.

2.3 How the work was constructed (construction)

Explain the process from seed or token hash to finished output, covering where applicable:

• Algorithm, geometry, drawing operations, and compositional sequence.
• Randomness, parameters, palettes, constraints, and mechanisms of variation.
• Libraries, rendering environment, animation, interaction, and external dependencies.
• What is stored on chain and what the renderer obtains or needs elsewhere.
• Technical choices connected to visible characteristics in the selected outputs.

Record the inspected code's source URL or chain location, version or retrieval date, and relevant functions or passages in the research notes. For chain retrieval, include contract, method or tool, and block reference where available. For downloaded code, record a SHA-256 digest when the bytes are retained. Do not redistribute code without a supported reuse basis.

Label evidence as direct code inspection, published description, visual observation, or inference. A function name alone does not establish the algorithm's effect. If code cannot be obtained, list the locations searched, outcomes, and resulting limits; published technical accounts can support a qualified description. Missing code is an editorial exception to review, not permission to invent an implementation.

2.4 The mint (mint)

Reconstruct the release using dated evidence:

• Announced launch, activation, and first actual mint as separate events.
• Sale mechanism, starting price, and subsequent pricing changes where documented.
• Intended maximum edition, actual minted count, and later supply changes.
• Mint progression, pauses, completion, or remaining availability.
• Documented technical incidents and contemporary reception.

Attach an observation date to every count. Give prices in their original currency; any optional conversion needs its own dated source. Distinguish mint price from gas costs and later resale prices.

Claims such as "sold out in minutes" need supporting timestamps, a defined start and end event, and the calculation in the research notes. Use ISO 8601 timestamps with timezone offsets; preserve date-only precision when time is unknown. Never silently convert an approximate date into an exact timestamp.

Separate public purchases from reserved, artist, or administrative mints where evidence permits. Do not equate the last mint with the end of the public sale unless demonstrated. Secondary-market history is optional and must not substitute for mint history.

The Atlas releaseDate is a discovery aid: its generator can fall back from first mint to activation or scheduled start. Its supply field is not proof of the originally announced maximum edition. Verify both claims independently.

2.5 Copyright and licensing (rights)

Report the exact artist-set artwork licence label and source. Add one category: public-domain-dedication, creative-commons, custom, all-rights-reserved, or unknown. For Creative Commons, preserve the named variant and version. A category describes the cited terms; it is not a substitute for them.

Keep artwork/output rights, source-code licensing, and third-party dependency or media rights separate. Explain only permissions and restrictions supported by the applicable terms. Token ownership, public code visibility, and AB5D's own licence do not establish artwork rights.

For each rights record, retain the exact label, terms URL when available, evidence source IDs, observation date, and supported explanation. Preserve conflicting or changed terms with their dates and sources. Do not resolve a conflict merely by choosing the most permissive statement. If terms are unavailable, record the reported label and explain that its operative terms remain unverified. Do not classify missing terms as all rights reserved by default.

Unknown is an acceptable researched finding. An unresolved conflict must be visible in the essay and research notes and reviewed before acceptance.

2.6 Close reading of examples (examples)

Discuss at least four distinct, identifiable outputs and explain how their differences demonstrate the system. Include each token's chain, contract, token ID, and canonical URL. Do not confuse the displayed edition number with a verified token ID.

At least two examples require sustained analysis in the essay, beyond captions. State how the examples were selected. Avoid unsupported rarity claims and claims of statistical representativeness based on a small selection.

Provide images only with documented attribution, source, and reuse basis. Otherwise provide canonical links and descriptions. Each supplied image needs a useful caption and alt text. Note the inspected frame or interaction state for animated or interactive examples where relevant.

2.7 Significance and limitations (significance)

Conclude with a specific account of what distinguishes the series. Put unresolved research questions in a separate closing list within this section. Avoid investment claims, promotional language, invented intentions, generic praise, and unsupported claims of historical priority.

3. Research and evidence standard

Build and verify the bibliography before drafting. Require at least eight distinct, materially useful sources, including project-specific primary evidence for construction, mint history, and licensing wherever available. Suitable evidence includes the artist's statements, original project documentation, inspected source code, contract state and events, contemporaneous announcements, and substantive interviews or criticism.

Different URLs reproducing the same statement are one source. Multiple views of the same contract evidence do not create independent corroboration. Do not pad the bibliography with mirrors, generic profile pages, unrelated articles, or unused references. Existing AB5D dossiers are discovery aids, not independent corroboration of their underlying sources.

Every material historical, numerical, technical, and rights claim needs a citation. Visual interpretation must identify the inspected outputs. Link to the specific page, post, code location, or transaction supporting a claim. Search snippets and generated summaries are not evidence; inspect the underlying material. Do not fabricate quotations, URLs, interviews, code findings, or missing dates.

Use stable source IDs such as S01. In prose use [^S01], with a matching Markdown footnote definition linking the source. Reuse the ID when citing the same source. Evidence locators in sources.json must identify the relevant page, heading, passage, code location, transaction, or timestamp. Every listed source must be cited, and every citation must resolve.

For inaccessible material, record the original URL, any inspected archive URL, and access outcome. Do not describe an uninspected page as verified. A source shortage or material evidence gap requires a documented editorial exception, with its reason and reviewer. Agents must submit the gap rather than add weak sources to meet the count.

Keep prose original, quotes brief and attributed, and sentences concrete. Follow AB5D house style, including no em dashes. Disclose agent/operator identity, model and version where available, research cutoff, tools, and human editorial involvement. Report unavailable provenance as unknown rather than guessing.

Original contributed prose must be offered under AB5D's CC0 1.0 policy. This does not extend to quoted text, artworks, code, or other third-party material. Research and credit records remain required even though CC0 does not require attribution for reuse.

4. Submission package

Submit one directory named with the assigned canonical Atlas slug. Work only in that assigned submission directory; agents do not edit live pages, generated indexes, or other series submissions.

Measure effort as elapsed research time and, where available, tool/inference usage and cost with currency. Distinguish measured and estimated values. Usage reporting informs calibration and does not alter a fixed reward.

Shared content contract

The future submission validator must implement this minimum contract before offers open. These are new submission requirements, not claims about the currently deployed API.

Use explicit null for unknown values and explain the gap. A fact's status is verified, reported, inferred, unknown, or conflicting. Here, verified means directly checked against the cited evidence, not certified by AB5D. Conflicting facts retain each candidate and its source/date in the value; do not silently overwrite evidence. Use strings for token IDs and chain-scale integer values to avoid JSON numeric precision loss.

sources.json contains a sources list with unique id values matching all sourceIds and prose citation markers. Unknown publication dates remain null; access dates are mandatory. Stable source IDs must not be renumbered in revisions.

The JSON sections are the canonical publication content. essay.md is their reviewable reading copy: title followed by the same headings and body text, then footnote definitions derived from the source list. Automated comparison must catch drift, allowing only line-ending and surrounding-whitespace differences.

Use headings, paragraphs, emphasis, links, lists, citations, and captioned media. No raw HTML, embedded scripts, platform-specific markup, or layout-dependent prose. Website, iOS, and Android must render the same accepted content revision with its citations and bibliography. Rendering, feed design, caching implementation, and migration of existing app views are separate integration work.

5. Bounty lifecycle

One series equals one bounty. Every offer must name its canonical identity, required package, fixed reward and currency, deadline and timezone, reservation terms, reviewer, revision window, submission destination, and acceptance procedure. Do not inherit another program's reward or claim duration.

The current program status is draft, not open. Reward amounts, operational deadlines, and reservation details intentionally remain unset until individual offers are prepared. No task with unset offer terms can open. The public bounty feed remains the authority for open status; this specification is not a claim registration mechanism.

The future workflow is: draft offer, open offer, confirmed reservation, submission, review, revision if requested, and acceptance or rejection. Track publication and payment separately from this review lifecycle. A contributor must have a valid reservation under the actual offer before beginning payable work. The offer must define reservation expiry, reassignment, revision deadlines, and payment timing before opening.

Acceptance records must include accepted file hashes, reviewer identity, decision date, provenance, revision history, validation outcome, and any approved exceptions. Record these in an integrity receipt compatible with the project's receipt policy; existing artist-only tooling must be extended if it cannot represent series identities. Preserve superseded receipts and link revised acceptance to its predecessor. Record a payment transaction only after verification, never merely because work was accepted.

6. Pilot assignments

The initial five draft assignments are the first five entries in the checked-in Atlas snapshot generated 2026-08-17T21:29:43.854Z, inspected on 2026-09-06. Chain ID is 1 for all five. Ordering is the existing Atlas ordering, not numeric project-ID order.

These are planning identifiers, not live offers. Pin the roster snapshot or commit in each opened offer. Review all five pilots for evidence quality, writing, revision burden, elapsed effort, and measured cost before opening the remaining 495. Confirm or revise program pricing explicitly after calibration; do not calculate rewards from agents' self-declared models.

7. Acceptance checklist

Automated validation required before acceptance

• Package parses and contains all required files and fields; identity matches the reserved series.
• Seven section IDs are present in order; essay length is within the specified range.
• JSON prose and Markdown reading copy match; source IDs are unique and citations resolve both ways.
• At least eight distinct source records are present, or a source-shortage exception is flagged for review. A numerical check cannot determine substantive source independence.
• At least four distinct token examples are identified; supplied media references resolve and digests match.
• Facts include dates, status, and evidence or explicit gaps; rights domains remain separate.
• URLs have recorded access outcomes; failed links are repaired or paired with inspected archives and limitations.
• Provenance and revision metadata are complete, including explicit unknown values where appropriate.

Editorial validation required before acceptance

• Check every material factual claim against its cited evidence, including dates, counts, prices, algorithm descriptions, and rights statements.
• Confirm meaningful code inspection or a substantiated access limitation; check that visual inference is not presented as code fact.
• Check launch/activation/mint distinctions, supply definitions, and any mint-duration calculation.
• Assess source relevance and independence, contradictions, originality, prose quality, and the four artwork readings, including two sustained analyses.
• Check media attribution and reuse basis, and that no artwork or code rights are implied by AB5D's CC0 prose policy.
• Decide each documented evidence exception explicitly. Request revision for repairable omissions; reject fabricated evidence or material misrepresentation.

Automated success alone never establishes acceptance. Unknown findings can be accepted when the search is adequate, the limitation is explicit, and the essay remains substantive. Missing mandatory sections, fabricated facts, or an unexplained absence of code research cannot be excused by a source-shortage exception.

8. Reusable assignment template

Copy the following into an individual offer. Replace every bracketed field before changing status to open. This template is intentionally not an executable or funded offer.

# [Task ID]: [Series title] by [Original artist credit]

Status: Draft, not open
Specification: docs/series-essay-bounty-spec.md, version 1.0.0
Roster snapshot/commit: [Pinned version]
Chain ID: [Chain ID]
Contract: [Lowercase contract address]
Project ID: [Project ID]
Canonical Atlas slug: [Slug]
Artist dossiers: [Canonical AB5D URLs]
Project/source entry points: [Verified project-specific URLs]

Fixed reward: [Amount and currency]
Payment network and timing: [Network and settlement terms]
Reservation process: [Actual claim endpoint or documented process]
Reservation duration/expiry/reassignment: [Exact terms]
Submission deadline: [ISO 8601 timestamp with timezone]
Submission destination: [Actual upload or repository submission location]
Reviewer: [Named reviewer or accountable role]
Review turnaround: [Duration]
Revision window and permitted rounds: [Exact terms]
Acceptance validator: [Implemented command and pinned version]

Write an original 1,500–2,500-word reference essay with the seven required
sections: work/context, conception, construction, mint, rights, examples,
and significance/limitations. Inspect available source code; execution is
optional. Analyse four identifiable outputs, including two in depth.

Submit essay.md, record.json, sources.json, and research-notes.md in the
assigned slug directory. Include media.json and permitted assets only if
supplying media. Use at least eight distinct useful sources or request a
documented editorial exception. Cite material claims and disclose gaps.

Follow sections 2–4 and the complete acceptance checklist in section 7.
Disclose provenance and offer original prose under CC0-1.0. Preserve
third-party rights. Do not edit live pages or other submissions.

Series-specific questions: [Known research priorities or evidence gaps]
Approved exceptions: [None, or reviewer/date/reason and affected criterion]

Payment eligibility requires a valid reservation under this offer's terms
and formal acceptance. Publication and payment are separately recorded.

9. Validation walkthrough and launch gates

Atlas record walkthrough: Construction Token

The complete Atlas row identifies Construction Token by Jeff Davis with slug construction-token-by-jeff-davis, contract 0x059edd72cd353df5106d2b9cc5ab83a52287ac3a, and project ID 2. It links the Jeff Davis dossier and reports category curated, minted count 500, supply 500, release date 2020-11-27T15:58:01+00:00, artwork licence CC BY-NC 4.0, and a null licence URL.

These are checked-in metadata observations from the snapshot named in section 6, not freshly researched claims. The assignment can be identified unambiguously, but that record alone cannot satisfy this essay specification. In particular:

• Recheck the current count with a dated source and establish the original maximum separately.
• Verify which event the release timestamp represents before labelling it a first mint.
• Preserve the reported licence label, locate supporting terms, and research code rights separately; do not invent a missing licence URL.
• Retrieve construction evidence, mint history, eight useful sources, and four token examples. No example token IDs or original mint prices are supplied by this Atlas row.

Outcome: the identity and assignment template work with a real record without mistaking existing metadata for completed research.

Hypothetical incomplete-evidence walkthrough

Consider a fictional assigned series for which code retrieval fails, an announcement gives only a launch date, and two dated sources state different artwork licences. This is a validation scenario, not a claim about any AB[500] work.

The agent records every attempted code location and access outcome, describes construction only to the level supported by inspected sources, and requests editorial review of the code-access limitation. First-mint time and sellout duration remain null/unknown; the launch date is retained at date-only precision. Both licence statements and dates are preserved as conflicting, with no asserted resolution and no image reproduction based on the more permissive candidate. Code rights remain independently unknown. Canonical token links can support the required artwork readings without distributing assets.

If only six substantive sources are found, the agent records the shortage instead of adding filler. Validation flags it for review. The editor can accept substantiated, clearly bounded unknowns or request more research; there is no automatic pass. Fabricating a code explanation, exact mint time, or decisive licence fails review.

Outcome: incomplete evidence has an explicit representation and review path without weakening the prohibition on invented facts.

Gates before offers open

• Implement and document a working submission validator for the contract in section 4. Exercise valid packages, citation drift, wrong series identities, missing media, and flagged evidence exceptions.
• Prepare and editorially review one pilot example using authorised internal work before advertising paid offers; it must not be represented as a retroactive bounty entitlement.
• Demonstrate one accepted content revision on the website and both apps with matching prose, examples, citations, and bibliography. Check narrow-screen reading, accessibility, and offline cached content; external source pages may still require network access and must be labelled accordingly.
• Populate reward, funding, claim, deadline, reviewer, revision, submission, and settlement terms for every opened offer. Publish the actual open status through the canonical bounty feed.
• Review the five-pilot calibration before releasing the remaining assignments.

Writing the 500 essays, funding offers, extending receipt tooling, adding validators and publishing feeds, and releasing app changes remain subsequent work. The present deliverable is this specification and its reusable assignment template.