“Worker_demi_proxy V5.8.3 extends the UplitAU Publishing Registry Worker so that every registration automatically self-anchors a 70-byte payload to Ethereum, tracks pending/confirmed states, and exposes dry-run, cron, and manual-anchor modes without ever blocking a registration.”
PropositionsT1: After each registration the Worker signs a 0 ETH self-transaction (70-byte payload: DEMI+version+prefix+register digest+file SHA-256) from the anchor wallet and records it as PENDING with its tx hash immediately | T2: If broadcast completes within 7 seconds the tx hash is returned in the registration response; otherwise anchoring finishes in the background and appears on the certificate | T3: CONFIRMED state is set when a receipt is observed via background poll, certificate view, or cron | T4: The cron handler confirms pending anchors and sends catch-up anchors for any uncovered record; it is a no-op when nothing is pending | T5: _index now stores extract_sha256 and core_sha256 (SHA-256 of canonical JSON of five Core fields; null if Core withheld/absent); existing entries are unchanged | T6: Manual anchoring (POST mode 'anchor') accepts old 32-byte digest or new 70-byte payload; confirming a known-pending hash marks it confirmed rather than rejecting it | T7: POST mode 'anchor-dryrun' signs a real anchor and reports address, nonce, fees, and would-be hash without broadcasting; POST mode 'anchor-cron' runs the cron body on demand | T8: The certificate shows 'submitted … awaiting confirmation' with Etherscan link while pending, and block number once confirmed; /registry/{UPL}.json gains an 'anchor' object | T9: V5.7 features (REGISTER ONLY, visibility states, owner key) remain fully additive and do not break V5.6 interfaces
ConstraintsANCHOR_PRIVATE_KEY: 64-hex secret, accepted only if it derives ANCHOR_WALLET | ANCHOR_WALLET: required for anchoring | ANCHOR_AUTO='on': must be set to enable automatic anchoring | ANCHOR_MAX_FEE_GWEI: default 30 | ANCHOR_RPC_URL: optional fallback, empty by default | Broadcast timeout: 7 seconds for synchronous response; remainder handled in background | Payload size: exactly 70 bytes | Anchoring must never block or fail a registration | fetch() signature: (request, env, ctx); scheduled() handler required | Cron trigger configured externally: Worker -> Settings -> Triggers -> Cron Triggers (e.g. '0 * * * *') | Visibility states: listed, unlisted, sealed; sealing only at registration time, cannot re-seal a listed record | Owner key stored as SHA-256 only, issued once | core_sha256 is null when Core is withheld or absent | Records with neither file fingerprint nor Core are rejected when core_requested is true
MechanismsT1: Verify post-registration that _index contains a PENDING anchor entry with a tx hash before broadcast confirmation | T2: Test with a mock RPC responding in <7 s and confirm tx hash appears in registration JSON response; test with >7 s response and confirm hash appears on certificate only | T3: Simulate receipt arrival via background poll and certificate view; assert state transitions to CONFIRMED | T4: Invoke POST mode 'anchor-cron' with pending and uncovered records; assert pending become confirmed and uncovered receive anchors; invoke with no pending and assert no-op | T5: Register a new record and inspect _index for extract_sha256 and core_sha256 fields; confirm pre-V5.8 entries are unmodified; confirm core_sha256 is null when Core withheld | T6: POST mode 'anchor' with 32-byte digest and with 70-byte payload; confirm both accepted; re-submit a known-pending hash and confirm it is marked confirmed not rejected | T7: POST 'anchor-dryrun' with admin_token; assert no broadcast occurs and response contains address, nonce, fees, would-be hash; test with ANCHOR_AUTO off | T8: Fetch certificate while anchor is pending; assert Etherscan link present; fetch after confirmation; assert block number present; fetch /registry/{UPL}.json and assert 'anchor' object present | T9: Submit a registration from a V5.6 interface; assert record stored identically to V5.6 behaviour and V5.7/V5.8 fields absent or null
BoundariesOut of scope: changes to V5.6 or earlier record formats; modification of existing _index entries for extract_sha256/core_sha256; re-sealing a record once it has been listed; serving filtered views beyond what _index stores (privacy is storage-level only); consensus or finality logic beyond receipt detection | Planned but not built: no additional RPC providers beyond ANCHOR_RPC_URL fallback are described | OPEN: exact canonical JSON serialisation order for core_sha256 computation is not specified; behaviour if ANCHOR_RPC_URL is also unavailable after primary proxy fails is not described; maximum retry count or backoff strategy for background anchoring is not stated; definition of 'uncovered record' triggering catch-up anchor is not fully specified