Imprint - Log Provenance

If you use only one node from the ImprintAI pack, it's this one. Imprint - Log Provenance is the step that takes your finished generation, computes a fingerprint of it, and asks the ImprintAI service to write an immutable record of that generation onto the Bitcoin SV blockchain. Everything else in the pack - the label, the C2PA export, the verify node - is about carrying that one reference forward and proving it later. No Log, no provenance.

Why would you want a generation on a blockchain at all? The pitch is provenance you can't quietly edit away: anyone who has your image's transaction id can check, years later, that a particular generation existed with a particular model and hash, without trusting ImprintAI's servers to stay up. It's a cousin of the C2PA "Content Credentials" world that Adobe and Microsoft push - except instead of a signed manifest that a host can strip, this rides on a public ledger. Whether that trade matters to you is a judgment call; the pack is honest that prompts you submit may end up published unencrypted on a public blockchain, so you shouldn't be logging your private prompt text raw.

How it works

Drop it after your VAE decode (or after the encoder that wrote your actual file). Give it an image and it does two local jobs before anything leaves your machine:

• It computes the icph1 canonical pixel hash - a SHA-256 over the RGB bytes with the least-significant bits zeroed out, prefixed with the dimensions. Zeroing the LSBs is the trick that makes this hash survive steganographic label embedding, so the labelled copy you distribute later still matches the on-chain record.
• It derives a deterministic input_summary_hash from the model, prompts, version, type, and any workflow JSON you feed it.

Then, if enable_logging is true and you've supplied an API key, it POSTs that metadata to https://imprintai.link/api/imprint and waits - polling for a bounded time while the anchor broadcasts. Only a real, confirmed transaction earns a 64-hex txid with anchor_ready=true. Anything else - a mock response, a pending job that times out, an API outage - returns an empty txid and anchor_ready=false, and the pack deliberately refuses to treat a job id as a provenance reference. That strictness is the whole point: a label that says "provenance confirmed" when nothing was actually anchored would be worthless.

The inputs and outputs that matter

Three required inputs have defaults you can mostly ignore: model (defaults to SDXL - set it to what you actually used), api_key (leave blank if IMPRINT_API_KEY is in your environment), and enable_logging. That last one is your privacy master switch: when false, the node still computes all three hashes locally but makes no network call at all. If you're unsure whether you want your metadata on a ledger, that's the setting to flip.

Worth knowing about the optional inputs: prompt, negative_prompt, and workflow_inputs_json are the things that can go public on-chain - put a summary or nothing rather than your full private prompt. output_file_path is special: point it at the exact bytes of an already-saved file and the node adds an output_hash (SHA-256 of those exact bytes), deliberately kept separate from the in-memory image hash so the record matches the distributable file, not the tensor. previous_txid chains this record to an earlier one.

The outputs are txid (the 64-hex reference or empty), anchor_ready (the gate), output_hash, canonical_pixel_hash, and input_summary_hash. Wire txid and anchor_ready into Imprint - Label Image for a stego-only workflow, or into Imprint - Export Labelled PNG (+ C2PA) for a file with a signed manifest.

Installing

Not on the ComfyUI Registry yet, so Manager search may come up empty. Install manually:

cd ComfyUI/custom_nodes
git clone https://github.com/svcBSV/imprintai-comfyui.git
cd imprintai-comfyui
python -m pip install -r requirements.txt

Restart ComfyUI completely. The only dependencies are requests and Pillow, both already bundled with ComfyUI, and you need an approved account/API key from imprintai.link before anchoring will actually succeed.

Common issues

The two you'll actually hit: anchoring is "temporarily unavailable" (the service returns no txid, console prints exactly that - your workflow is fine, the broadcaster isn't) and "No API key provided" (your environment variable isn't reaching the ComfyUI process). Neither is a node bug. And if you see an anchor_ready that never goes true while enable_logging is on, check whether your account was actually approved - the API will take your request and politely never finish.