Qwen-Image-2.1 on RTX 4090: all three models resident at 1 MP in ComfyUI

What You'll Build

A ComfyUI graph on one RTX 4090 that generates images from text at up to native 2048×2048, with a real alpha channel when you ask for one, and edits images against up to ten references — all from one 7B checkpoint and ComfyUI's own bundled templates.

On a 24 GB card the interesting question is not whether Qwen-Image-2.1 fits. It is which text-encoder file you download, because that decides whether the transformer, the encoder and the VAE can all stay on the card at once. With the official template's int8 encoder they can at 1 megapixel, with room to spare, and native 2K comes close. With the bf16 encoder that ComfyUI's own tutorial page lists as the text encoder to download, they cannot, and weights get paged on and off the card as the stages alternate. This page installs the template's files and shows the arithmetic for every alternative.

⚠️ Non-commercial only. Qwen-Image-2.1 is released under the Qwen Research License Agreement, not an open-source licence. Section 1.i defines the permitted use as one that "shall mean for research or evaluation purposes only." and Section 2.a grants the rights "FOR NON-COMMERCIAL PURPOSES ONLY". Section 2.b routes commercial use to a separate licence requested by email — and a user in discussion #7 reports that "the email in your licensing page immediately bounces back". The grant is worldwide: there is no territory clause. Section 4.b reaches outputs too — if you use the model or anything it generates to create, train, fine-tune or improve an AI model that you distribute or make available, its documentation must display "Built with Qwen" or the equivalent wording the clause gives. The Comfy-Org repack installed below does not relicense anything, and a community re-quantisation is a derivative work under Section 3, still bound by Section 2. This is a reader's summary, not legal advice; the linked agreement is what binds you.

Hardware data: RTX 4090 (24GB VRAM) · all three models resident at 1024²: 16.096 GiB of weights, 18.245 GiB with the legacy loader's reserve (derived, not measured) · See benchmark data

Requirements

The three files the official text-to-image template loads, from the Comfy-Org repack at revision ace0edeb37:

The repack also carries a bf16 transformer (14,230,280,616 B = 13.253 GiB), a bf16 encoder (17,534,334,616 B = 16.330 GiB) and a w4a8 encoder (6,312,105,364 B = 5.879 GiB). Its diffusion_models/ folder holds exactly two files, bf16 and int8 — there is no FP8 or NVFP4 transformer from Comfy-Org, whatever your card supports.

What 24 GB actually buys

Which loader this describes. On this install ComfyUI does not use a memory estimate to decide what stays on the card. v0.37.0 turns on DynamicVRAM on any NVIDIA device when PyTorch is 2.8 or later and comfy-aimdo initialises (main.py); the v0.37.0 portable log in issue #16441 prints DynamicVRAM support detected and enabled. Under it, weights load on demand and are evicted only when an allocation needs the room. free_memory() in comfy/model_management.py skips them, with the comment "don't actually unload dynamic models for the sake of other dynamic models". ModelPatcherDynamic.partially_load() in comfy/model_patcher.py never reads the memory budget it is handed. The only standing reserve is a live check against the VRAM actually free at the time. On Linux that is comfy-aimdo's VRAM_HEADROOM of 256 MiB (src/plat.h at v0.5.5). On Windows it is 512 MiB, checked against both the WDDM budget and NVML's free-VRAM reading, or 96 MiB if it falls back to cuMemGetInfo (src-win/shmem-detect.c at v0.5.5). --reserve-vram does not remove that check. It raises a second budget, which comfy-aimdo compares against the card's total capacity, and the larger of the two deficits applies — so on Linux, values below 256 MiB change nothing (comfy_aimdo/control.py at v0.5.5). It also sets the legacy loader's EXTRA_RESERVED_VRAM. To keep more VRAM free for other software under DynamicVRAM, the flag is --vram-headroom, which adds on top of both.

The reserve arithmetic below is therefore the legacy, estimate-based loader's — what you get with --disable-dynamic-vram, --highvram, --gpu-only, --novram or --cpu. It stays here because it is still the best physical budget available: weights, plus ComfyUI's own estimate of how much working memory each stage needs.

Under that loader, load_models_gpu reserves the larger of two things on top of the weights. One is the floor minimum_inference_memory() — 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB (0.391 GiB) on Linux and 700 MiB on Windows for a card over 15 GiB, so 1.191 GiB or 1.484 GiB. The other is the stage's own memory estimate plus EXTRA_RESERVED_VRAM. Two estimates matter here:

• Transformer: memory_usage_factor = 6.0 for this model (comfy/supported_models.py), which under PyTorch attention works out to 0.480 GiB at 1024² (a 64×64 latent) and 1.920 GiB at 2048². At 1024² that is under the floor, so the floor binds.
• VAE decode: 900 × h × w × 256 × dtype_size over the latent grid (comfy/sd.py), with the VAE in bf16 on this card: 1,887,436,800 B = 1.758 GiB at 1024², and 7.031 GiB at 2048². This is the largest reserve at both sizes.

So, weights for all three modules plus the worst stage's reserve, on Linux:

transformer  int8     7,256,783,064 B =  6.758 GiB
encoder      int8     9,350,798,360 B =  8.709 GiB
VAE          bf16       675,509,688 B =  0.629 GiB
decode estimate @1024²  1,887,436,800 B =  1.758 GiB
EXTRA_RESERVED_VRAM       419,430,400 B =  0.391 GiB
                                          ──────────
                                          18.245 GiB   against 24 GiB:  5.755 GiB spare

On Windows add 0.293 GiB to every reserve and budget.

The 1024² conclusion holds under either loader. The template's 16.096 GiB of weights leaves 24 − 16.096 = 7.904 GiB of a nominal 24 GiB. That is far more than comfy-aimdo's live headroom (256 MiB on Linux, 512 MiB on Windows), and more than the legacy loader's 2.148 GiB decode reserve, so all three models stay on the card and a prompt change only re-runs the encoder.

The 2048² row is not a fit claim. It comes within 0.482 GiB of a nominal 24 GiB, and three things the budget leaves out are each of that order. load_models_gpu asks free_memory for 1.1× the model it is about to load, which adds 0.063 GiB for the VAE. ComfyUI measures against the capacity the driver reports, which for this card is slightly under 24 GiB. And the CUDA context occupies memory too. Expect some paging, or ComfyUI's tiled-decode fallback, at native 2K rather than a clean all-resident run.

A budget over the card does not mean an out-of-memory error either. Under DynamicVRAM, weights that do not fit are paged: loaded when a stage needs them, evicted when another allocation needs the room, and staged back from system RAM or disk later. The author of PR #16430 describes it for this model after that PR's change as "Higher VRAM utilization, more TE retained" — how much of the text encoder stays on the card follows the memory pressure. The 6920MB Staged line in that PR's log is not evidence of paging: it is the size of the weights set up for on-demand loading, exactly the int8 transformer file, and it prints on every run. What a budget over the card costs is traffic. With the encoder in that rotation, every prompt change pays it.

Two cautions on those numbers. They are weights plus ComfyUI's own estimates, not a measured peak — the only measured 4090 peak for this model I found is from a different runtime (see Results), and at 22.7 GiB it is a reminder that a real working set carries allocator and CUDA-context overhead these estimates leave out. And a card that also drives your desktop gives some of its memory to the compositor before ComfyUI starts.

The 12 GB in the frontmatter is not this card's number and is not a peak. It is the smallest capacity the site's own derivation covers for this exact install — the same three files and template — and the derivation for a 12 GB card is on this model's RTX 3060 page.

Installation

1. ComfyUI v0.37.0 on a CUDA 13 PyTorch

Qwen-Image-2.1 support is in ComfyUI core — nodes TextEncodeQwenImage21 and QwenImage21Cache, no custom node pack — from PR #16400, merged 2026-09-19. The first release carrying it is v0.37.0: the tag was cut on 2026-09-20 and the release, with Windows portable builds attached, was published on 2026-09-21. The bundled templates declare "minComfyUIVersion": "0.37.0" in the templates index, and v0.37.0's requirements.txt pins comfyui-workflow-templates==0.11.66, the templates release that switched the encoder to int8. Two later Qwen-Image-2.1 changes — #16429 (edit-cache placement) and #16430 (compiled transformer blocks) — merged after the tag and are only on master.

The CUDA version is a gate in ComfyUI's own source. comfy/quant_ops.py reads torch.version.cuda; below 13 it disables comfy-kitchen's CUDA backend and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." That is not a failure: comfy-kitchen falls through to its eager backend, whose int8_linear still serves the int8_tensorwise + convrot layers — it rotates activations and quantises them in PyTorch, then calls torch._int_mm — so the model runs, only slower. Install the CUDA 13 stack last, from its own index, because requirements.txt lists torch unpinned and can otherwise pull a default wheel over it:

git clone https://github.com/Comfy-Org/ComfyUI.git   # skip if you already have a checkout
cd ComfyUI
git fetch --tags && git checkout v0.37.0
pip install -r requirements.txt
pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
  torch torchvision torchaudio

On Windows, the v0.37.0 release's ComfyUI_windows_portable_nvidia.7z is the alternative; a v0.37.0 portable startup log posted in issue #16441 reports pytorch version: 2.14.0+cu130. The release also ships a portable whose file name ends in _cu126 — a CUDA 12.6 build would sit below the gate.

Check two lines in the startup log before going further:

pytorch version: 2.14.0+cu130
Found comfy_kitchen backend cuda: {'available': True, 'disabled': False, ...

Read the disabled field, not only available. The gate works by calling registry.disable("cuda"), which in comfy-kitchen's registry adds the backend to a disabled set and leaves it registered, so under a CUDA 12 build the same line should read 'available': True, 'disabled': True — or 'available': False with an unavailable_reason, if comfy-kitchen's compiled extension does not load at all. Either way it is not the line above. On the first generation ComfyUI then prints Using mixed precision operations and a Native ops: … , emulated ops: … line (pick_operations in comfy/ops.py). On an RTX 4090, int8_tensorwise must be on the native side — supports_int8_compute() returns True on any CUDA device — and nvfp4 and mxfp8 will be on the emulated side, because supports_nvfp4_compute() needs compute capability 10 or higher and this card is 8.9.

2. Download the three model files

Run this from the ComfyUI root. The repack's own paths are diffusion_models/, text_encoders/ and vae/, so --local-dir models lands the files where the loaders look:

pip install -U huggingface_hub

hf download Comfy-Org/Qwen-Image-2.1 \
  diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
  text_encoders/qwen3vl_8b_int8_convrot.safetensors \
  vae/qwen_image_2.1_vae_bf16.safetensors \
  --local-dir models

Then check the hashes. This is launch week, and the repack's transformer files were already replaced once, on 2026-09-19, after the vendor's own checkpoint update that day — so a hash tells you which file you actually have:

sha256sum models/diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
          models/text_encoders/qwen3vl_8b_int8_convrot.safetensors \
          models/vae/qwen_image_2.1_vae_bf16.safetensors
# cb74113cb03faecd79611b01fd7fd642f0aa60d6f0b95086abee214d75eaa57d  qwen_image_2.1_int8_convrot
# 8bfd0f6e12abf2d2d697ecc888e5e90b0d6741d6708f05799f53afa560452e8f  qwen3vl_8b_int8_convrot
# bb21f7473051e1ac368515dd3f2e15cd44d7a11748ee8823e1ddca3e4876b7c9  qwen_image_2.1_vae_bf16

If you already run another ComfyUI model on Qwen3-VL-8B, you may have the encoder already. The text encoder is the stock Qwen3-VL-8B-Instruct, not a fine-tune: the vendor's text_encoder/ shards and Qwen/Qwen3-VL-8B-Instruct hold the same 750 tensor names and the same total size, and every tensor sampled from both over HTTP range reads — six, from the vision tower to lm_head — is byte-identical; the same comparison run against a different checkpoint of the same architecture differs on all six, so the method can tell them apart. Two readers reached the same conclusion independently in discussion #5. Comfy-Org's qwen3vl_8b_int8_convrot.safetensors carries the same sha256 in the Qwen-Image-2.1 repack and in Comfy-Org/Qwen3-VL — reuse the copy you have.

3. Load the official template

In ComfyUI open Template Library and pick Qwen Image 2.1: Text to Image, or drag in image_qwen_image_2_1_t2i.json. Its loaders are already set to the three files above, with the encoder loaded as CLIPLoader type qwen_image.

Running

python main.py

Queue the template unchanged first. The values that actually run live on the outer subgraph node, not on the inner widgets: 25 steps, cfg 1, euler / simple, and a ResolutionSelector set to 1:1 at 1 megapixel, which drives the latent to 1024×1024. The vendor's own diffusers example uses 40 steps at 2048×2048 and passes no guidance setting at all; the template's note puts the cfg side as "cfg: keep 1 for the Qwen Image 2.1 official path. Raise it only if you use a negative prompt." Raising cfg above 1 makes ComfyUI run a conditional and an unconditional pass, normally batched together, which doubles the transformer's estimate — 0.960 GiB at 1024², 3.840 GiB at 2048² — and puts two passes through the transformer on every step. In the budget above the decode reserve stays the larger one, so cfg does not change the residency picture.

Output lands in ComfyUI/output/ as a PNG via SaveImageAdvanced (8-bit, sRGB).

Native 2K

Set the ResolutionSelector to 1:1 at 4 megapixels for 2048×2048; the template's note lists the other 2K ratios. The budget there comes within a few hundred MB of the card (row 2 above and the paragraph after it), so expect some paging or a tiled decode rather than a clean all-resident run. The decode is the tight step. If the full-image decode does not fit, ComfyUI does not fail: VAE.decode catches the out-of-memory error, logs Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding. and decodes in tiles.

Transparent images

Qwen-Image-2.1's VAE outputs four channels. The vendor README's example wraps the subject in two fixed sentences: "This is an RGBA image with transparency." before it and "The image has alpha channel and the background is transparent." after it. Keep the PNG output — a JPEG throws the alpha away. ComfyUI also ships a Remove Background: Qwen Image 2.1 template that uses the same three files.

Editing

The Qwen Image 2.1: Image Edit template (image_qwen_image_2_1_image_edit.json) loads the same three files and adds a QwenImage21Cache node. image_1 is the image being edited and fixes the output canvas; further inputs are references you name in the prompt as <image1>, <image2> and so on. Its resolution starts at 0 — the template's note: "This template starts at 0: no resize beyond a multiple of 32." — so each reference keeps its own size.

Set resolution to 1056 before you edit. ComfyUI issue #16435 reports edits that come out broken — over-sharpened and speckled — when the grid a reference resolves to lands on certain sizes, and its two reports disagree on which sizes those are. The original report, from an Apple M5 Max on both MPS and the CPU, found a 1024×1024 grid broken while every other value in its sweep, from 512 to 1152, was clean. The reporter's follow-up comment adds that the template's resolution=0 reaches that grid with any 1024×1024 image. A second report comes from an RTX 5070 Ti on the v0.37.0 tag, running the official edit graph with the bf16 transformer rather than this page's int8 one. There a 1024×1024 reference was clean, but a 1536×1024 reference was broken, with the edit instruction ignored as well. It broke the same way at resolution=0 and at resolution=1248, which resolve to the same grid, while 512, 1024, 1056 and 2048 were clean. The two setups differ in more than the backend — encoder precision (bf16 against int8), reference image, step count, operating system, build and attention path — so backend is one possible explanation for the disagreement, not an established one. That commenter notes both failing grids are multiples of 2,048 tokens (4,096 and 6,144) — an observation, not a confirmed cause. Both reports found resolution 1056 and 512 clean. Use 1056 instead of the template's 0, because 512 shrinks the reference to a quarter-megapixel budget. PR #16444 links the issue as a proposed fix, currently marked draft; it is unmerged, comes from a first-time contributor, and was validated with unit checks only, not on the model. The issue is open as of 2026-09-21. Disconnecting the VAE from the encode node also removes the artefact, at the cost of much weaker adherence to the reference.

The edit cache holds the text and reference tokens' keys and values for the whole run — the reason edits are faster than a full recompute. At cfg 1 it costs 2 × 32 blocks × 4,096 × 2 bytes per prefix token, so 0.488 GiB per 1,000 tokens, and one 1024² reference alone is 4,096 tokens, 2.000 GiB. At v0.37.0 the auto setting takes the first of VRAM and system RAM that has more than four times the cache size free, and if neither does, it recomputes the whole prefix on every step (comfy/ldm/qwen_image21/model.py). With this page's files on the card, the VRAM side cannot pass for a single 1 MP reference: 7.904 GiB of a nominal 24 GiB is under the 8.000 GiB it would need. The author of PR #16429 adds that the VRAM test "gets disrupted by smart memory + dyn vram" anyway. The RAM side needs more than 8 GiB free per 1 MP reference, and the same PR says the tag's check "requires 4x RAM to be free and doesnt account the pin quotas at all". Its body shows the fallback at this tag: an RTX 5080 with 32 GB of RAM ran what the PR's author captions Full recompute fallback, on an edit with two reference images, at 4.01 s/it, against 1.02 it/s after the fix, which landed after v0.37.0.

If an edit runs far slower than a generation, set the cache node's device to cpu. That skips the four-times test; it still needs twice the cache size free in RAM, or it recomputes. The node's own tooltip in comfy_extras/nodes_qwen.py says of that choice: "auto uses spare VRAM, then RAM. cpu (RAM) is prefetched behind compute and costs little speed." off recomputes the prefix every step and is the setting to use if you suspect the cache itself.

Optional: the bf16 transformer

Swapping UNETLoader to qwen_image_2.1_bf16.safetensors adds 6.495 GiB and costs the co-residence: with the int8 encoder, the budget comes to 24.739 GiB at 1024², over the card, so under DynamicVRAM some weights are paged off while a stage runs and staged back when the next prompt needs them. The transformer on its own is 13.253 GiB and sits on the card comfortably. What the swap would buy is reference precision, and nobody has put a number on that for this file pair: I found no int8-versus-bf16 comparison for Qwen-Image-2.1 in either HuggingFace discussion tab, in PR #16400 or in the HN launch thread as it stood on 2026-09-21. The nearest published figure is vLLM-Omni's FP8 table, measured on a GB200 with a different quantisation scheme and a different runtime, so it says nothing directly about ComfyUI's int8 convrot file. Pairing the bf16 transformer with the bf16 encoder the tutorial page lists needs 30.212 GiB of weights and cannot co-reside on any 24 GB card.

What Ada's FP8 does, and does not do, here

The RTX 4090 has FP8 tensor cores; Ampere cards do not. For this model in ComfyUI v0.37.0 that difference is idle, for three separate reasons, each read from the files or the source:

• The transformer is not an FP8 file. Every one of the eight quantised layers sampled (of 192) from qwen_image_2.1_int8_convrot.safetensors carries {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} with no full-precision opt-out, so it runs INT8 matmuls — which Ada and Ampere both have. Comfy-Org publishes no FP8 transformer to switch to.
• The encoder is dequantised however it is stored. Quantised text encoders load through mixed_precision_ops(..., full_precision_mm=True) in comfy/sd1_clip.py; only the generate() path lifts that, and Qwen-Image-2.1's encode path does not use it. So Comfy-Org's qwen3vl_8b_fp8_scaled.safetensors would be routed to the same qwen_image loader branch — the branch matches on the model's tensor layout, not its storage format — but its FP8 weights would be expanded for every matmul, and it is 1.153 GiB larger than the int8 file. Open PR #16432 proposes native matmuls for NVFP4 encoders only, on cards that support NVFP4 compute.
• Community NVFP4 transformers gain nothing on this card. ComfyUI marks nvfp4 as emulated below compute capability 10, so those layers are dequantised too.

Results

• Speed: our catalogue has no benchmark rows for this pair — /check/qwen-image-2-1/rtx-4090 returns verdict: unknown. The only timing for this card in a convrot format that I found is a comment by vunderba in the HN launch thread: "a 1MP image took around ~5 seconds on an RTX4090", using what he calls QwenImage2.1 convrot. What it does not state: which convrot build — this page's int8 file, or the community INT4 ConvRot build created at 14:43 UTC that day, an hour before the comment — nor the step count, the runtime, whether the text encode is inside that time, or the PyTorch/CUDA build. Treat it as one person's order of magnitude, not as a figure for the template's 25 steps.

  A second, controlled measurement on this card comes from a different runtime entirely. SGLang's documentation publishes an RTX 4090 row in its Qwen-Image-2.1 cookbook: 18.68 s per text-to-image and 21.68 s per edit at 1024², 40 steps, cfg 1, native bf16, with the placement "DiT and VAE resident, encoder layerwise offload" and FlashAttention, measured on 2026-09-20 as median HTTP latency after warmup including PNG serialisation. That is bf16 rather than int8, 40 steps rather than 25, and a server rather than ComfyUI, so it is not a prediction for this page's install and it does not contradict the HN figure either — the two share nothing but the card.

  For native 2K I found no 4090 timing at all. The only ComfyUI one I found is in the body of PR #16430: an RTX 5090 (Linux, 96 GB RAM) generating five 2048×2048 images in one batch at 25 steps took 3.51 s/it — 87 s for the five — before that PR's compile change, and 3.40 s/it after it, which landed after v0.37.0. A newer and larger card, so it is an optimistic ceiling this card will not reach, not an estimate for it. If you time the template on a 4090, at either size, /contribute is where that number belongs.

• VRAM usage: at 1024² the transformer, encoder and VAE all stay resident: 16.096 GiB of weights, 18.245 GiB with the legacy loader's 2.148 GiB decode reserve, leaving 5.755 GiB of the card. At native 2048² the same budget reaches 23.518 GiB, within a few hundred MB of the card, so expect some paging or a tiled decode there. Both are derived from byte counts and ComfyUI's own constants, not measured by us. The only measured peak for this model on a 4090 that I found is SGLang's 22.7 GiB, for its bf16 configuration with the encoder offloaded layer by layer. Live data, when it exists, will be at /check/qwen-image-2-1/rtx-4090.

• Quality notes: the templates run at cfg 1, where the negative prompt is unused. vunderba, after running his benchmark, wrote "I found that I had to play with dialing up the CFG depending on the complexity of the prompt"; budget for the doubled sampling cost if you do. A reader in discussion #12 reports a diamond-grid pattern that is "more noticeable when you generate a high-resolution image that has people with light skin tones and zoom in on their faces", and adds that you can reproduce it with "Or just passthrough a source image to the VAE, no other processing needed" — which points at the VAE rather than your card. The only mitigations offered in that thread are third-party post-processing, and none of its commenters is a member of the Qwen organisation as of 2026-09-21. The two qwen3.5_9b_qwen_image_2.1_pe_* files in the repack are prompt-enhancer language models for rewriting your prompt, not text encoders — loading one in the CLIPLoader gives garbage, per Comfy-Org discussion #4.

For the full benchmark data, see /check/qwen-image-2-1/rtx-4090.

For the 2025 20B Qwen-Image on this card — a different model with a different licence — see its RTX 4090 recipe.

Troubleshooting

TextEncodeQwenImage21 or QwenImage21Cache is missing

Your ComfyUI predates the support. Both nodes arrived with PR #16400 and first shipped in a release in v0.37.0; before that release existed, readers of Comfy-Org discussion #1 hit exactly this, and the fix there was updating to the latest commit. Check that the startup log reads ComfyUI version: 0.37.0 or later.

Generation is far slower than the figures above

Grep the startup log for the cu130 warning quoted in Installation step 1, or for a comfy-kitchen import error. Either silently moves the int8 layers onto the eager backend while ComfyUI carries on normally. Then confirm the Native ops line lists int8_tensorwise on the native side.

An edit comes out over-sharpened and speckled, or ignores the instruction

Check the grid the edit resolved to — see the Editing section and issue #16435. The two reports so far disagree on which grids fail. Both found resolution 1056 clean, and 512 as well, though 512 shrinks the reference; use 1056.

Ran out of memory when regular VAE decoding at 2048²

That is ComfyUI switching to tiled decoding, not a failure — the image still arrives. If it happens on every 2K run, something else is holding VRAM: a second workflow's models, or a desktop that has taken more of the card than usual.

A shape error such as expected input with shape [*4096] from the encoder

The file in the CLIPLoader is not the Qwen3-VL-8B encoder, or its type is not qwen_image. In Comfy-Org discussion #2 that exact error turned out to be the wrong file loaded.

Nothing here matches your problem

Runtime errors belong at ComfyUI/issues, template problems at workflow_templates/issues, model questions at the model's discussion tab. If you get a clean run on this card, a timing sent through /contribute is worth more to the next reader than every derived number on this page.