Contribution intake operations

The claim queue accepts review requests, not payment instructions. It stores no signing key, fetches no evidence URL, and has no payout action. The public gateway has only the dedicated queue directory mounted; the curator reviews evidence through separate local tools. Do not publish the form until its actual intake service and persistence have been verified.

Prepare the dedicated storage

These maintainer commands prepare an empty directory under the project and set its container ownership. They work with Docker's user mapping, including rootless Docker; host UID numbers are not assumed to equal container UID numbers. They refuse existing contents rather than change an active database.

mkdir -p state/claims
docker run --rm --network none --read-only --cap-drop ALL --cap-add CHOWN \
  --security-opt no-new-privileges --user 0:0 --tmpfs /tmp:size=8m \
  --mount "type=bind,src=$PWD/state/claims,dst=/state/claims" \
  ghcr.io/astral-sh/uv:0.11.16-python3.12-trixie-slim@sha256:438bad5bb636f6cc60765ed25f294c74dd896e6d14b2093c3467a37b5d03a78a \
  uv run --no-project --no-config --no-cache --no-python-downloads python -c \
  'import os; from pathlib import Path; p=Path("/state/claims"); assert not any(p.iterdir()), "Existing claim state: preserve it"; os.chmod(p,0o700); os.chown(p,65534,65534)'

The opt-in compose.claims.yaml adds /app/claim_queue.py read-only and state/claims at /state/claims to web-gateway. It sets TOKN_CLAIMS_DB=/state/claims/requests.sqlite. No deployment is performed by preparing that file. Enabling the overlay restarts a public service and belongs to the separately reviewed deployment step.

Publication and failure behavior

The actual origin GET /claims/health must report schema tokn-claim-intake/1, accepting: true, persistenceReady: true and paymentAuthorized: false. Verify an isolated request, exact retry and Docker restart before any production intake launch. Never use a real person's evidence for an infrastructure test.

The release publisher and Cloudflare builder inspect only this project's running web-gateway, require the exact persistent claim mount and current loaded source, then query its local health. This prepares one atomic Worker-route and asset update without requiring a public route before that update exists. Verify the public /claims/health and form immediately after a reviewed publication. --claims-fixture is restricted to unpublished builds under dist/; it is not production evidence. A normal offline source build omits the form and explains the existing named-agent route. Health never exposes queue records. Public queue listing and individual-request reads do not exist.

The Worker forwards a claim POST once, strips visitor authentication and cookies, and applies its API rate gate. The origin accepts JSON up to 8 KiB. The queue has two concurrent database slots, a short busy timeout, at most 10,000 retained rows, 20 new requests per hour globally and two per wallet per day. It stores no IP or user-agent. These bounds reduce abuse; wallet counts do not prove unique people. Do not claim anonymous or permissionless unlimited intake.

Review and authorize separately

The queue directory is deliberately owned by the gateway's container UID and is not readable by the ordinary host user. Use the bounded, network-disabled review container rather than changing those permissions:

just claim-list
just claim-list 1234                 # continue before an earlier sequence
just claim-export REQUEST_UUID       # copy one request to state/grants/

Without just, invoke scripts/claim-review-container.sh with the same list or export arguments. It runs scripts/claim-review.py through the pinned uv image as the queue UID. The database connection is read-only; the bind mount is writable only because SQLite WAL readers must lock sidecar files. The container has no network, drops all capabilities, and has bounded CPU, memory and process counts. export prints the complete review envelope and writes the same request to the protected state/grants/ directory; it does not approve or pay a claim.

Compare the exact artifact bytes and SHA-256, the requested recipient and the actual useful result. A queue receipt establishes neither usefulness nor wallet ownership. A node request additionally needs the existing chain/genesis/header and ten-block checks. The optional claim signature is verified offline using the original request time; its presence alone is not approval.

The separate curator reward command requires a locally approved grant record, the exported request and evidence. It derives the stable wallet identity for human intake, validates the requested amount and receipt, verifies WorkVault, and preserves signed transaction bytes before broadcast. It is a deliberate payment action. An accepted intake response is never permission to run it.

Keep queue and reward journals in encrypted recovery backups. Stopping the gateway or removing its container preserves the bind-mounted queue. Never delete the database or transaction journals to clear a pending claim or retry a payout.