cronum is a public, open standard. Anyone is free to implement their own uploader or viewer, or make proprietary changes to the standard for their own organizations needs. If you have changes that you would like to see incorporated into the public standard, please contact us.

Please note: This page is technical and is intended for developers who wish to build their own cronum uploader or viewer. The standard is still a draft at this time, while we’re working on the implementation of all the necessary supporting pieces.

Status: Draft v1.1 (proposed).
This update formalizes two reference implementations of the NFU Uploader:

• NFU Uploader (Public): public attachments and text-only unlockables (no encrypted media).

• NFU Uploader (Verified): adds encrypted media unlockables (images/audio/video/3D/PDF) for verified creators/collections only, enforced via an allowlist and a Safety Manifest.

The spec adds optional v1.1 fields for encrypted-media support and safety metadata; it remains backward-compatible with v1.0.

Scope: Defines how creators attach public files and unlockables to existing NFTs and how viewers verify authenticity (EIP-712 proof), time (Arweave block timestamp), eligibility (ownership at timestamp or allowlist), and safety policy (Safety Manifest + blocklists) prior to decryption and display.

• The Public build implements public files and text-only unlockables.

• The Verified build additionally implements encrypted media unlockables gated by Lit Protocol and restricted to wallets/collections in an allowlist (managed separately).

• Both builds emit Descriptor JSON and NFU-Proof artifacts compatible with this standard.

1) Design goals

• Two deployment tracks:

  • Public build: simple, broadly accessible; never enables encrypted media.

  • Verified build: enables encrypted media unlockables only for approved wallets/collections; requires allowlist + Safety Manifest checks.

• Safety-by-design: A public Safety Manifest in the Descriptor records plaintext SHA-256 (and optional perceptual hashes) plus policy signals. Viewers MUST consult local/remote blocklists and MAY refuse key retrieval or decryption if flagged.

• Clear access control: Encrypted media keys are released only when Lit access-control conditions are satisfied and the uploader/viewer passes policy checks (e.g., allowlist for upload, revocation lists for view).

• No key custody: All cryptography is end-user controlled; decryption happens client-side.

• Time & identity anchors:

  • Arweave is the clock (Descriptor Tx block timestamp).

  • Ethereum is identity (EIP-712 NFU-Proof binding fileHash + descriptorTxId + NFT tuple to the uploader).

• Viewer eligibility rule: Render only if the uploader owned the NFT at the Arweave timestamp (or appears on the verified allowlist) and safety checks pass.

• Deterministic audit trail: Post (a) data (for public files or encrypted media), (b) Descriptor JSON (L1), and (c) NFU-Proof (L1) so any party can independently verify the state.

• Progressive compatibility: v1.1 fields are optional; older viewers ignore unknown fields without breaking baseline behavior.

2) Artifacts & Descriptor JSON (v1.1)

This section defines the canonical on-chain/off-chain artifacts and the Descriptor JSON structure used by both uploader builds:

• NFU Uploader (Public) — supports public files and text-only unlockables (no encrypted media).

• NFU Uploader (Verified) — additionally supports encrypted media unlockables for verified creators/collections.

2.1 Required artifacts

• Data Tx (Arweave)

  • Public build: the raw public file.

  • Verified build (encrypted media): the ciphertext of the media (not the plaintext).

• Descriptor JSON (Arweave, L1) — machine-readable description of the attachment.

  • Acts as the clock: viewers MUST use the Descriptor’s Arweave block timestamp for “time of upload.”

  • v1.1 adds fields for encrypted media and the Safety Manifest.

• NFU-Proof (Arweave, L1) — EIP-712-signed proof binding the upload to the uploader and the NFT tuple.

  • MUST include: fileHash (plaintext hash), arweaveTxId (Descriptor id), contract, tokenId, standard, erc1155Amount, uploader.

All three artifacts SHOULD be linked to each other via tags and/or URLs for easy discovery.

2.2 Descriptor JSON (v1.1)

2.2.1 Common fields (all builds)

Requirements

• schema MUST be nfu.descriptor.v1.

• kind MUST be public or unlockable.

• tokenId MUST be a decimal string (no hex).

• standard MUST be erc721 or erc1155.

2.2.2 Public files (both builds)

Add a storage pointer to the raw file:

Viewer rule: Render directly (no decryption needed). Safety checks MAY still be applied to URLs and metadata.

2.2.3 Unlockables — Public build (text-only)

For text unlockables, encryption output is embedded in the Descriptor:

Viewer rule: Before requesting keys, MAY consult Safety Manifest if present (optional in Public build for text).

2.2.4 Unlockables — Verified build (encrypted media)

Encrypted media uses a ciphertext Data Tx plus explicit crypto metadata:

Viewer MUST:

1. Validate mime_whitelisted === true, size_ok === true, and blocklist_match === false (and/or perform its own checks).

2. Consult local/remote blocklists and any revocation lists; if flagged, the viewer MUST refuse key retrieval/decryption.

3. Obtain Lit key only after safety checks pass, then decrypt and render by MIME.

2.2.5 Backward compatibility

• v1.1 fields (storage for encrypted media, crypto, safety_manifest) are optional.

• Older viewers MUST ignore unknown fields without failing baseline behavior (public files and text unlockables remain compatible).

2.3 Validation (normative)

Implementations MUST enforce:

• NFT identity: contract is a valid EVM address; tokenId is decimal; standard ∈ {erc721,erc1155}.

• Timestamps: createdAt is ISO-8601; authoritative time is the Descriptor’s Arweave block timestamp.

• Hashes: hashes.sha256 MUST be the SHA-256 of the plaintext (not ciphertext).

• Encrypted media (Verified build): storage.dataTxId MUST reference the ciphertext; crypto.alg MUST be AES-GCM; ivB64 MUST be present.

• Safety: If safety_manifest is present, viewers MUST evaluate it and MAY augment with their own checks; if any mandatory check fails, decryption MUST NOT proceed.

3) Upload, confirmation & NFU-Proof

This section defines the canonical upload flow, the NFU-Proof (an EIP-712 signed receipt), and the linkage between the Data Tx, the Descriptor JSON (authoritative “clock”), and the Proof. It applies to both uploader builds:

• Public build: public files + text-only unlockables.

• Verified build: adds encrypted-media unlockables for verified creators/collections.

3.1 Overview (high level)

1. Prepare content & metadata.

   • Compute required hashes (see §3.3).

   • If encrypted media (Verified build): encrypt client-side and produce a ciphertext blob + crypto metadata.

2. Post Data (if applicable).

   • Public file → post raw file to Arweave as Data Tx.

   • Encrypted media → post ciphertext to Arweave as Data Tx.

   • Text-unlockable (Public build) → no Data Tx required (ciphertext or pack may be embedded in Descriptor).

3. Post Descriptor JSON (L1).

   • Always post a Descriptor as an L1 Arweave transaction.

   • Viewers MUST use the Descriptor’s Arweave block timestamp as the authoritative upload time.

4. Wait for confirmation.

   • Implementations SHOULD obtain at least 1 Arweave confirmation and record the block height/timestamp.

5. Create & post NFU-Proof (L1).

   • Sign the EIP-712 NFU-Proof with the uploader’s EVM wallet and post it to Arweave (L1).

6. Link artifacts.

   • Use tags/fields so Data ⇄ Descriptor ⇄ Proof are discoverable (see §3.5).

3.2 NFU-Proof (EIP-712) — normative

The NFU-Proof binds the plaintext content (or the exact public bytes) to the Descriptor and the NFT tuple, signed by the uploader’s wallet on the relevant EVM chain.

3.2.1 Domain (recommended)

Implementations MAY change name/version, but SHOULD keep a stable domain across releases.

3.2.2 Types (required)

4) Eligibility & Safety Evaluation

This section defines what a viewer MUST check before rendering any attachment and in what order. It applies to both uploader builds, with additional rules for the Verified (encrypted-media) build.

4.1 Goals (summary)

• Prevent decryption/rendering when policy or safety checks fail.

• Make results deterministic across viewers.

• Keep privacy: never transmit plaintext to third parties during checks.

4.2 Inputs

A conforming viewer relies on:

• Descriptor JSON (L1) — authoritative “clock” via its Arweave block timestamp (see §2).

• NFU-Proof (L1) — EIP-712 receipt (see §3).

• Allowlist Manifest — from NFU Guard (or equivalent), read-only JSON containing approved wallets/collections and a flag enforceMediaAllowlist.

• Blocklists — local + remote (e.g., SHA-256, pHash) used for pre-decryption safety decisions.

• Revocation List — JSON of descriptorTxId and/or hashes that official viewers MUST refuse to show.

The Allowlist/Blocklist/Revocations MAY be served by your own endpoint(s) and SHOULD support ETag/Cache-Control.

4.3 Upload-time checks (creator client) — SHOULD

Before any posting (especially for encrypted media), the creator client SHOULD:

1. Validate allowlist (verified build only; uploader wallet or collection is allowed).

2. Compute plaintext hashes (SHA-256; optional pHash / video keyframe pHashes).

3. Check blocklists → if any match, abort.

4. Build Safety Manifest and include it in the Descriptor draft (see §2).

These checks reduce the chance that permanent storage receives disallowed content.

4.4 View-time gate (mandatory order)

A viewer MUST evaluate in the following order before requesting/releasing any decryption key:

1. Descriptor integrity

   • Fetch Descriptor (L1) and confirm it exists.

   • Record its Arweave block timestamp t_A (authoritative upload time).

2. Revocation check

   • If descriptorTxId (or its hashes in Safety Manifest) appears in a revocation list, STOP (do not decrypt or render).

3. Kind & build rules

   • If kind=public → proceed to §4.8 (Proof/ownership) and render without decryption.

   • If kind=unlockable + Public build (text-only) → continue.

   • If kind=unlockable + Verified build (encrypted media) → continue and apply §4.6 (allowlist) and §4.7 (safety).

4. Safety Manifest (if present)

   • Validate shape; if malformed, viewer MAY refuse to continue for encrypted media.

   • If checks.blocklist_match === true or checks.mime_whitelisted === false or checks.size_ok === false → STOP.

5. External blocklists (local/remote)

   • Recompute/confirm Descriptor-provided hashes (when possible) and compare to configured blocklists.

   • On match → STOP.

6. Key-release gating (unlockables only)

   • Only if steps (1)–(5) pass, request Lit key per lit.uacc.

   • If policy requires “ownership-at-time” (below), a viewer MAY preflight that check before requesting the key to avoid unnecessary key traffic.

7. Decrypt (unlockables)

   • Decrypt client-side (never upload plaintext).

   • Compute keccak256/SHA-256 of plaintext for §4.8 verification.

8. Proof & eligibility (all kinds)

   • Verify NFU-Proof, historical ownership (or allowlist), then render.

4.5 Ownership-at-time rule (normative)

Definition: The uploader must have owned the NFT at t_A (the Descriptor’s Arweave block timestamp), or the uploader wallet/collection must appear on a configured allowlist (policy choice).

• ERC-721: resolve ownerOf(tokenId) over time; prove that the uploader EOA controlled the NFT at t_A (by locating adjacent transfer events or using an indexer capable of point-in-time ownership).

• ERC-1155: prove balanceOf(uploader, tokenId) > 0 at t_A.

Viewer MUST implement one of:

• Strict mode (recommended): require uploader ownership at t_A. If ambiguous, treat as not eligible.

• Allowlist override: if uploader (or the NFT’s collection) is on the allowlist, ownership-at-time MAY be waived (policy dependent).

4.6 Allowlist policy (verified build)

• If enforceMediaAllowlist=true, uploaders of encrypted media MUST be in the allowlist (by wallet) or the NFT’s contract MUST be in an approved collection allowlist.

• A viewer MUST check that the uploader recovered from the NFU-Proof signature is allowlisted (directly or via collection rule) when policy is enabled.

4.7 Blocklists & Safety checks

• Hashes to check:

  • hashes.sha256 (Descriptor) / safety_manifest.hashes.sha256_plaintext (same value)

  • Optional safety_manifest.hashes.phash (images)

  • Optional safety_manifest.hashes.video_keyframe_phash[] (videos)

• Outcome: Any positive match in configured blocklists (local or remote) MUST result in no key request and no rendering.

• Network hygiene (optional): Check URLs in Descriptors against anti-abuse URL feeds; a positive match SHOULD prevent rendering external links.

4.8 Proof & content verification (post-decryption where applicable)

For all attachments, the viewer MUST:

1. Verify NFU-Proof (see §3): recover signer; ensure the message fields match Descriptor/NFT tuple.

2. Recompute fileHash:

   • Public file: from raw bytes (Data Tx).

   • Unlockable: from plaintext after decryption.
     Compare to fileHash in the EIP-712 message; on mismatch → STOP.

3. Eligibility: Apply §4.5 (ownership-at-time or allowlist).

4. Render if and only if all checks pass.

4.9 Decision outcomes (recommended)

Viewers SHOULD expose a consistent decision code for analytics and user messaging:

• OK_RENDER — all checks passed.

• BLOCK_REVOCATION — revoked by policy list.

• BLOCK_BLOCKLIST — matched a forbidden hash/URL.

• BLOCK_ALLOWLIST — media not permitted for this uploader/collection.

• BLOCK_PROOF — invalid or mismatched NFU-Proof.

• BLOCK_ELIGIBILITY — uploader not owner at t_A (and no allowlist override).

• BLOCK_DESCRIPTOR — malformed or missing required fields.

• BLOCK_DECRYPT — Lit key denied or crypto error.

4.10 Caching & freshness (recommended)

• Allowlist/Blocklist/Revocations: respect Cache-Control and ETag; refresh opportunistically in the background.

• Safety Manifest: trust only as a hint; recompute hashes when feasible (e.g., after decryption).

• Fail-safe: on network errors fetching policy lists, default to conservative (do not request keys for encrypted media).

4.11 Privacy & logging (non-normative)

• Never upload plaintext or user media to third-party services during view checks.

• Log only high-level decisions (codes above) and artifact ids (descriptor/data/proof); avoid any PII beyond wallet addresses.

4.12 Minimal viewer sequence (pseudocode)

5) Policy Manifests (Allowlist, Blocklists & Revocations)

This section standardizes the JSON manifests that viewers and uploaders consult for policy decisions. Implementations MAY serve these from any origin; paths shown are examples only.

5.1 Goals

• Provide deterministic, cacheable inputs for eligibility and safety.

• Keep payloads small and schemas stable so third-party viewers can comply.

• Permit soft failures to default to conservative behavior.

5.2 Allowlist Manifest (wallets & collections)

Purpose: Indicate who may upload encrypted media (Verified build) and whether enforcement is active.

• URL (example): /wp-json/nfu-guard/v1/manifest

• Cache: Cache-Control: public, max-age=300 and ETag MUST be supported.

• Schema (normative):

6) Cryptography & Access Control (normative)

This section standardizes how encrypted media unlockables are produced (Verified build), how keys are controlled, and how viewers decrypt and verify them. Text-only unlockables (Public build) reuse a subset of these rules.

6.1 Algorithms & parameters

• Symmetric cipher: AES-256-GCM (256-bit key).

• IV / nonce: 96-bit random per encrypted object. Never reuse an IV with the same key.

• Auth tag: 128-bit (GCM tag).

• Key material: 32 random bytes (cryptographically secure RNG).

• Encoding: raw bytes for crypto; public fields encoded as:

  • ivB64: Base64 (URL-safe not required).

  • Ciphertext: stored as raw bytes in the Data Tx (recommended), or Base64 if embedded (text-only path).

• Hashing (dual discipline):

  • keccak256(plaintext) → used in NFU-Proof.fileHash (EIP-712).

  • sha256(plaintext) → stored in hashes.sha256 and in safety_manifest.hashes.sha256_plaintext.

Rationale: AES-GCM provides confidentiality + integrity; dual hashes support both EVM tooling (keccak) and safety tooling (sha256).

6.2 Lit access control (UACC profiles)

Implementations MUST use Lit Protocol access control conditions (UACC) that are equivalent to:

• ERC-721 (single owner):

8) Conformance & Feature Registry

This section defines who implements the standard, what must be implemented at each level, and a simple feature registry so third-party sites and apps can advertise support.

8.1 Roles

• Creator Client (Uploader): builds artifacts and posts them (Data Tx, Descriptor, NFU-Proof).

• Viewer: evaluates eligibility/safety and renders content.

• Policy Server: serves allowlist/blocklist/revocation manifests (e.g., NFU Guard).

• Indexer (optional): caches/derives ownership-at-time data for faster viewer checks.

8.2 Uploader conformance profiles

• Uploader (Public-Conformant)
  MUST:

  • Produce Descriptor (L1) per §2 with schema:"nfu.descriptor.v1".

  • For public files: post Data Tx (raw bytes) + storage.dataTxId.

  • For text unlockables: embed encrypted pack (lit.packed) and include hashes.sha256 of plaintext.

  • Post NFU-Proof (L1) per §3 with fileHash = keccak256(plaintext-or-public-bytes).

  • Wait ≥1 Arweave confirmation on Descriptor before posting NFU-Proof.
    SHOULD:

  • Add basic App-Name/App-Version/NFU-* tags (§7.5).

• Uploader (Verified-Conformant)
  MUST implement all Public requirements plus:

  • Encrypted-media workflow per §2.2.4 / §6 (AES-256-GCM, crypto.ivB64, ciphertext in Data Tx).

  • Lit access control (UACC) per §6.2 and key save.

  • Safety Manifest populated and truthful (§2.2.4).

  • Preflight policy: fetch allowlist/blocklists/revocations and refuse upload on match (§4.3).
    SHOULD:

  • Enforce MIME/size whitelist (§6.6).

  • Include pHash / keyframe pHashes when applicable.

8.3 Viewer conformance profiles

• Viewer (Baseline) — supports public files and text unlockables.
  MUST:

  • Use Descriptor L1 block timestamp as the clock (§2).

  • Verify NFU-Proof and recompute fileHash from plaintext/public bytes (§3, §4.8).

  • Enforce ownership-at-time or declared policy (§4.5).
    SHOULD:

  • Honor revocation list; render only after ≥1 Descriptor confirmation.

• Viewer (Safe) — adds encrypted media & policy enforcement.
  MUST (Baseline +):

  • Apply revocation before anything (§4.4).

  • For encrypted media: require allowlist if policy says so (§4.6).

  • Apply blocklists before key requests; refuse on match (§4.7).

  • Request Lit key only after prechecks; decrypt client-side (§6.5).

  • Verify NFU-Proof using keccak256(plaintext) after decryption (§4.8).
    SHOULD:

  • Validate Safety Manifest shape/claims; recompute hashes post-decrypt.

• Viewer (Strict) — Safe + additional defenses.
  SHOULD:

  • Preflight ownership-at-time before key requests to avoid unnecessary key traffic.

  • Require pHash/keyframe pHash checks for images/video when present.

  • Fail closed on manifest/network errors for encrypted media (§4.10).

8.4 Required behaviors (matrix)

* For text unlockables, Public Uploader may omit a Data Tx (cipher embedded).

8.5 Feature registry (advertising support)

Implementations MAY publish a tiny capability file so other apps know what to expect. Suggested location:
/.well-known/cronum-capabilities.json

8.6 Self-test checklist (interoperability)

• Artifacts: Create known vectors (public file, text unlockable, encrypted image/video) and verify another implementation can:
  (a) discover artifacts via tags; (b) confirm Descriptor; (c) verify NFU-Proof; (d) enforce policy; (e) render.

• Negative cases: Ensure viewer blocks on each code path: BLOCK_REVOCATION, BLOCK_BLOCKLIST, BLOCK_ALLOWLIST, BLOCK_PROOF, BLOCK_ELIGIBILITY, BLOCK_DESCRIPTOR, BLOCK_DECRYPT.

• Timing: Validate “ownership-at-time” by testing uploads around a transfer boundary.

• Privacy: Confirm no plaintext or keys leave the client during checks/decrypt.

8.7 Versioning & upgrades

• This document is v1.1. New optional fields MUST NOT break existing viewers; unknown fields MUST be ignored.

• Future versions MAY add: chunked/streaming encryption, attested viewers, or additional ACC profiles; implementers SHOULD advertise support via the capabilities file.

Appendix A: JSON Schemas

Below are canonical JSON Schemas (Draft 2020-12) for implementers. They’re split into (A) base types, (B) Descriptor v1.1 (plus profiles), (C) NFU-Proof envelope, (D) Policy Manifests, and (E) Capabilities.

Notes
• Use these schemas for validation only; viewers still MUST apply the normative rules in §§3–6.
• Arweave IDs are Base64URL; we allow a safe range in the regex.
• Ethereum addresses/signatures are hex-encoded.

A) Shared base types

B) Descriptor JSON v1.1

B.1 Descriptor (base)

B.3 Profiles (validation helpers)

These optional schemas add constraints for each usage pattern.

Public file profile

Unlockable — text-only (Public build)

Unlockable — encrypted media (Verified build)

C) NFU-Proof (envelope posted to Arweave)

D) Policy Manifests

D.1 Allowlist (NFU Guard manifest)

D.2 Blocklist feed

D.3 Revocations

E) Capabilities file (feature registry)

How to use

• Host these at predictable URLs (e.g., /schemas/*.json) and reference via $id to enable $ref resolution.

• Validators: Ajv (JS), jsonschema (Python), everit (Java) all support Draft 2020-12.

• For Descriptor validation, apply the base schema then one of the profiles depending on the artifact type.