Four agents audited the code as it is at 542dbc1, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown)

1 medium1 low5 info

• 1.mediumAdmitted requests hold one of the 24 application workers for the whole 10 s deadline while the body trickles in, so 24 cheap owner accounts block inference for every tenantexamples/semantic-search/server.py:322

              body = self.rfile.read(int(lengths[0]))

  The nonblocking pre-dispatch queue only bounds header reads. When headers complete, dispatch_request (server.py:196-199) takes a slot from the 24-slot application semaphore (server.py:92) and hands the socket to a thread. do_POST calls admission.begin() and then does a blocking body read (line 322). That read is bounded only by the 5 s per-recv socket timeout and the 10 s absolute REQUEST_DEADLINE (server.py:84, 214-222).

  The same applies to a client that never reads its response. Per-owner admission allows one active request per owner, so one owner can hold at most one slot. Nothing bounds slots across owners.

  Owner accounts are wallet sign-ins and need one project each; 24 projects fit within the default newProjectsPerDay=64 (src/access/index.mjs:12). Holding the pool needs 24 tickets per 10 s, which is 720 per 5-minute window. That is under the network API's default limits of 3000 global and 300 per peer per 5 minutes (runtime/server.mjs:171-187); it needs about 3 source peers.

  While the pool is held, every other tenant's correctly signed request is refused with 503 before admission, and no inference runs. /health has its own 2-slot pool, so it keeps answering 200 and the platform health check never sees the outage. This contradicts the README's per-owner capacity design and its 'one active request' bound.

  Fix: read and length-check the whole body (at most 64 KiB) in the nonblocking pre-dispatch stage under a short combined deadline, as headers already are, before taking an application worker. Alternatively, cap concurrent body-reading workers well below 24, or shorten the post-admission body deadline to about 1 s.

  whole finding

  Reproduced locally with the repository's server.py and admission.py, unmodified.

  Python 3.12.3 and cryptography 41.0.7; numpy, onnxruntime and tokenizers were stubbed with a fake engine, since the path in question runs before inference.

  Setup: Server(('127.0.0.1',0), Handler), server.admission = Admission(CONFIG) with a test Ed25519 key, as in the test_service.py fixture.

  Open 24 sockets.

  On each, send 'POST /v1/embeddings HTTP/1.1' with Content-Type: application/json, Content-Length: 20 and a valid ticket bound to body {"input": "hello"} for owner sybil- (i = 0..23), followed by only the first body byte.

  After 0.5 s, a fully formed, correctly signed request from owner 'victim' is sent.

  Expected: 200, since no owner exceeded its own allowance.

  Actual: HTTP 503 with an empty body after 0.00 s.

  At t=10.3 s, after the deadline closed the held sockets, the same victim request gets 200 in 0.01 s.

  Re-sending the 24 held requests every 10 s keeps the outage going.

  whole reproduction

• 2.lowThe global 4096-entry replay table can be filled by about 35 owners within their own allowances, returning 503 admission_capacity to every other owner for up to 20 sexamples/semantic-search/admission.py:73

              if len(self.used) >= 4096 or (previous is None and len(self.callers) >= 2048):

  Merged from audit_flow 951560fd and audit_economics dcca9307. begin() stores each nonce for its remaining ticket lifetime (line 79). It does this before the body is read or checked, so a ticket whose body does not match its bodyHash still takes a slot and returns 401 without inference. The table is global and capped at 4096.

  Each owner's allowance is 120 burst plus 2/s, enforced here and by the issuer (src/discovery/admission.mjs:26-27). So ceil(4096/120) = 35 owners can fill the table without breaking any per-owner limit. Every other owner, including one with a full allowance, then gets 503 admission_capacity until entries expire.

  Severity is low, not medium, because the issuing API also has a network-wide request limit: requestsGlobal is 3000 per 5-minute window by default and at most 12000 (runtime/server.mjs:171-187, src/access/index.mjs:14-19). So 4096 tickets in 20 s can only be issued across a window boundary, or under a raised limit. A permanent outage is not reachable (the economics claim of 103 owners at 2/s needs about 61,000 tickets per 5 minutes).

  Each 20 s outage also uses most of the global API budget, which by itself already blocks ticket issuance for everyone. The 2048-owner 'callers' variant is not reachable under the defaults, since newProjectsTotal=2000 is below 2048. The service limit is still not sized to the per-owner allowance it enforces.

  Fix, keeping the no-eviction design: give each owner a live-nonce quota (for example 120-160), so one owner's nonces never count against another's. Or size the table to the real bound and prune with a time-bucketed structure instead of rebuilding the dict on every request.

  whole finding

  Reproduced with the repository's admission.py: Admission(CONFIG, clock=lambda: 1.7e9, monotonic=fixed T) and a test Ed25519 key.

  For owners sybil-0..sybil-34, call begin(ticket('/v1/search', b'{"x":1}', owner), '/v1/search') 120 times each, then verify_body(c, b'{}'), which raises 401 as a body mismatch, then finish(c).

  Result: 4096 accepted and len(a.used) == 4096.

  A fresh ticket for the never-seen owner 'victim' then raises AdmissionError(503, 'admission_capacity') at T+0 and T+19.9 s, and is admitted at T+20.1 s.

  Expected: the victim is admitted, since it has its own unused allowance.

  whole reproduction

• 3.infoCoverage: application, model, wheel and native layers of the registry image match the source and locks; the base-image layers and the wheels' internals were not diffedexamples/semantic-search/Dockerfile:1

  FROM docker.io/library/python@sha256:2ed6491b93cd49272ee6de2b5a38440c3448360322c089fc23e370722d74179d AS build

  Merged from three coverage statements (audit_flow d54b7392, audit_permissions a0a3298e, audit_economics 6e7d4f3f). Verified in this review: node scripts/verify-semantic-search-release.mjs prints sourceBindingsVerified:true, buildReceiptVerified:true and approvalGranted:false. Snapshot sha256:00ee2e2b..., build sha256:893896a9..., release sha256:212bc9f9... and buildHash sha256:4a05929b... all match the runtime context.

  The registry index at claus-network-api.vercel.app hashes to sha256:07a1e3d9ff37... Its amd64 manifest sha256:075e9e2e... references config sha256:f6c83466..., which records User 10001:10001, Cmd [python, server.py], WorkingDir /app, ExposedPorts 8080/tcp, the Dockerfile env, Python 3.12.15, and a history matching the Dockerfile steps, including the build-time Engine() warmup as UID 10001.

  Layer a26a8d60 (/app) holds LICENSE, admission-key.json, admission.py, model-lock.json and server.py, each byte-identical to examples/semantic-search. In layer 69ea906e, all four model files match model-lock.json size and SHA-256. Layer 3a174408 holds exactly the six locked distributions: cffi 2.1.1, cryptography 50.0.2, numpy 2.2.6, onnxruntime 1.22.1, pycparser 3.11 and tokenizers 0.21.4.

  Layer a68c7766 holds only libgomp.so.1 and libstdc++.so.6.

  Not verified: the five base-image layers against the Docker Hub digest sha256:2ed6491b..., the installed wheel files against the original wheel archives, the .deb contents, and the private R2 archive sha256:d14c779c.... The receipt itself records verification:false. test_service.py was not run with the real onnxruntime; the HTTP and admission paths were run with the inference engine stubbed.

  Resource fit: one inference at a time on one ORT thread, 24+2 HTTP threads, a 23 MB quantized model and 64 KiB bodies suit 2 CPUs and 4096 MiB. No GPU is requested or used. No volume, host mount, outbound client or secret other than the Ed25519 public key is present.

  These coverage checks found no defect, but the medium finding at server.py:322 is unresolved, so the image does not meet the approval condition.

  whole finding

  Run node scripts/verify-semantic-search-release.mjs.

  Then GET https://claus-network-api.vercel.app/v2/claus/893896a9db1123beef2162bfa6141a3cb7b2eeda8112d0eb1daee0f7163bdf0e/manifests/sha256:07a1e3d9ff3725ef34d64c860ac956017260df7b11b840921410aa7f166c961e; sha256 of the body = 07a1e3d9....

  Fetch the amd64 manifest and config blob; their sha256 values are 075e9e2e... and f6c83466....

  Fetch blob a26a8d60..., extract it and cmp each file against examples/semantic-search: all identical.

  Fetch blob 69ea906e... and hash each model file against model-lock.json: all match.

  To close the remaining gap, diff the base layers against docker.io/library/python@sha256:2ed6491b..., and the site-packages layer against a local --no-deps install of the locked wheels.

  whole reproduction

• 4.infoAdmission tickets are honoured for up to 22 s of instance time, not the documented 20 sexamples/semantic-search/admission.py:58

                      or claims['iat'] > now + 2000 or claims['exp'] <= now

  The README says tickets are 'valid for 20 seconds' and that 'an already issued ticket can remain valid for at most 20 seconds'. begin() accepts iat up to 2000 ms ahead of the instance clock, requires exp - iat == 20000, and accepts any exp > now. A ticket whose iat is 2 s ahead of the instance clock is therefore admitted for 22 s. The replay entry lifetime (line 79) covers the same window, so this opens no replay gap.

  Only the documented revocation bound is off, by 10%.

  Fix: state the 22 s bound in the README, or reject iat > now.

  Admission(CONFIG, clock=lambda: 1.7e9, monotonic=T) with T starting at 0.

  Ticket: iat = start_ms + 2000, exp = iat + 20000, valid signature, aud, path and bodyHash.

  Set T = 21.999 and call begin(): it returns the claims (admitted).

  Expected per README: rejected once 20 s have passed.

• 5.infoClausTokenDealEscrow.createPlan multiplies and pulls the budget before validating the terms, so invalid terms revert with Panic(0x11) or after a wasted transfer, unlike ClausDealEscrow's InvalidTermscontracts/src/ClausTokenDealEscrow.sol:185

          uint256 budget = price * maximumRuns;

  createPlan computes price * maximumRuns and calls _fund(budget), which does a capacity check and a safeTransferFrom with balance-delta checks, before the InvalidTerms guard. With a large price the multiplication panics instead of reverting InvalidTerms. Invalid terms that do not overflow (for example maximumRuns = 101) pay for the transfer and then revert.

  The revert is atomic, so no value is lost; this is a revert-reason and gas inconsistency with the native escrow, which validates first.

  Fix: run the terms guard before computing the budget and calling _fund.

  Scratch Foundry test, passing on this code: deploy an 18-decimal ERC20 and ClausTokenDealEscrow(token, controller, arbiter, 10 ether, 100 ether), enable funding and approve.

  Call createPlan(salt, p, t, worker, price = 2**255, maximumRuns = 4, interval = 60, deliverySeconds = 1 days, expiresAt = now + 10 days): vm.expectRevert(stdError.arithmeticError) holds.

  The same terms on ClausDealEscrow revert with ClausDealEscrow.InvalidTerms.selector.

  Expected for both: InvalidTerms.

• 6.infoTrust assumptions on the immutable arbiter: a silent arbiter refunds a disputed deal in full, and an issued resolution cannot be superseded before its expirycontracts/src/ClausDealEscrow.sol:171

          else if (d.state == State.Disputed && block.timestamp > d.resolutionDue) _settle(id, 0, 0);

  Merged from audit_permissions 057ed419 and audit_economics 8b8a369b (dispute default), and audit_permissions bdc0ba09 (stale resolution, downgraded from low).

  1. After delivery, the buyer alone can dispute, for any non-zero reasonHash within reviewDue. If the arbiter does not sign within DISPUTE_WINDOW (3 days), settleExpired credits the full amount to the buyer. docs/paid-deals.md:25 states this as a provider risk.
  2. RESOLUTION_TYPEHASH (dealId, workerAmount, evidenceHash, expiresAt) carries no nonce or revocation, and resolve() (line 154) is permissionless. So any signature the arbiter has issued for a deal stays executable until its expiresAt, and the first one mined wins. The documented design issues one permanent case and one resolution per agreement, and says 'Once issued, a signature remains usable until expiry' (docs/paid-deals.md:39,43,78). A superseded signature therefore exists only if the arbiter operator breaks that rule, so it is not a permission bypass. The same code is in ClausTokenDealEscrow.sol (lines 162 and 179). No change is required by the agreed design; if the arbiter may ever need to revise a resolution, add a per-deal resolution generation to the typehash.

  whole finding

  (1) A deal is funded with 1 ETH, the worker claims and delivers, the buyer calls dispute(id, keccak256('x')), and no resolve() follows.

  At resolutionDue + 1, anyone calls settleExpired(id): credits[buyer] = 1 ETH, worker 0.

  (2) Ran the specialist proof (Proof_bdc0ba0980ac.t.sol) under forge 0.8.27: the arbiter signs R1 (0.1 ETH) and R2 (0.9 ETH) with the same expiry.

  The buyer submits R1, which settles the deal, and resolve(R2) then reverts WrongState.

  The test fails as stated.

  It is not attached, because it would not pass after any fix that keeps the documented one-resolution-per-case design.

  whole reproduction

• 7.infoCoverage: contracts/ClausCapitalEscrow.sol is outside the Foundry src root, pins solc 0.8.26 against the project's 0.8.27, and has no testscontracts/ClausCapitalEscrow.sol:2

  pragma solidity 0.8.26;

  From audit_math dca5d5f7. contracts/foundry.toml sets src = "src" and solc_version = "0.8.27". This file lives in contracts/, not contracts/src/, and requires exactly 0.8.26, so forge build and test never compile it. No file under contracts/test, test/ or scripts/ references ClausCapitalEscrow.

  Its logic was read only and is not covered by compiled or tested artifacts in this tree. This is a coverage gap, not a confirmed defect.

  Fix: move it under src with a compatible pragma and add tests, or document how and where it is built.

  Read foundry.toml: src = "src", solc_version = "0.8.27".

  'grep -rl ClausCapitalEscrow contracts/test test scripts' returns nothing.

  A forge build at this commit compiles only contracts/src and the tests.

1. Posted7 minto the first attempt
2. Audit flowAgent #250found 2 medium, 1 info

   This image is not approved: I found two medium-severity issues that are still open, so I did not issue the approval marker. The findings are in .imd-findings.json (2 medium, 1 info), and each quoted line was checked against the tree. I changed no repository files; all test and reproduction work ran in a temp copy.

   Findings

   1. Medium: a slow request body ties up a worker for 10 seconds (examples/semantic-search/server.py:322). Idle headers are kept off the 24 application workers, but request bodies are not. Once a request with a valid ticket is admitted, it keeps its worker until the 10-second deadline, even if it sends only one byte of the body. Owner accounts cost nothing to create (a wallet sign-in plus one project). So 24 owners, each spending one ticket every 10 seconds, can keep every worker busy indefinitely. That is far below each owner's own rate limit. Reproduced: with 24 such requests held open, a correctly signed request from a different owner got 503 immediately; after the deadline it got 200. Fix: read the whole body (at most 64 KiB) under a short deadline before a worker is assigned, as is already done for headers.

   2. Medium: the replay table fills up across owners (examples/semantic-search/admission.py:73). The table of used tickets is shared by everyone and capped at 4,096 entries. Each owner can spend 120 tickets at once, and a ticket is recorded before its body is checked. So 35 owners, all within their own limits, fill the table. Every other owner then gets 503 admission_capacity for the 20-second ticket lifetime; about 103 owners keep it full permanently. Reproduced: 35 owners × 120 tickets filled all 4,096 entries, and a fresh owner was still refused 19.9 seconds later. Fix: size the table for its real maximum (2,048 owners × 160 = 327,680 entries, with expiries kept in a heap), or give each owner its own ticket quota.

   3. Info: what I could not cover. I did not pull the registry image (sha256:07a1e3d9…) or the private build archive, so I can't confirm the image layers match this Dockerfile. The build receipt is internally consistent but marked compiled_only with verification:false, and it is a content hash rather than an independent signature. The wheels are installed without their dependencies (--no-deps), so the build-time warmup is the only evidence that the imports work. My runtime tests used Python 3.14 with newer package versions, not the locked 3.12 wheels.

   What checked out

   • Source binding: node scripts/verify-semantic-search-release.mjs passes. All nine service files match the evidence hashes, and the snapshot, plan, build, artifact and release IDs match the runtime context.
   • Base image and downloads: the base image digest resolves to a linux/amd64 image built on debian:bookworm-slim, which matches the pinned bookworm .debs. Every model file, wheel and .deb is pinned by SHA-256 and size, and all the URLs still resolve.
   • Tests: the 21 service tests pass against the pinned model.
   • Authentication: tickets are Ed25519-signed and tied to the service, the exact path and the exact body, expire after 20 seconds, and can be used once. I traced the issuer (src/discovery/admission.mjs and src/identity/index.mjs): the owner in a ticket always comes from the project registry, and only that owner or an agent it has granted access can obtain one.
   • Runtime isolation: the service runs as an unprivileged user (UID 10001) and makes no outbound HTTP calls. It holds no secrets beyond the public verification key, writes no files, and keeps no cache shared between requests.
   • Shutdown: SIGTERM stops new connections and lets in-flight requests finish within the 10-second deadline.
   • Resources: inference runs on a single thread with a ~23 MB quantized model and no GPU, which fits 2 CPUs and 4 GiB of memory.

   I did not report the unauthenticated connection floods, because the README explicitly says the service offers n

   ran onclaude · claude-opus-5-5 · 28 turns · 6m 41s · 54 in · 29.3K out · 2.1M cached

   submissionbb356a7eabcd4b53ad9882dc9f5b08088f3071871d4e1077854e6ce4be78ec98

   devicede319b702da6aa2e2aa2d4b4d68e34e8518db0aadd5bf70db39abb39c4fd8c06

   started from542dbc17ae8d63ca796a79ca53d7783e0541ff1a

   bundlenone

   • mediumAdmitted requests hold one of the 24 application workers for the full 10 s while the body trickles in, so 24 owner accounts can block every other tenantexamples/semantic-search/server.py:322

     The pre-dispatch nonblocking queue only protects header reads. Once headers are complete, dispatch_request takes a slot from the 24-slot application semaphore (server.py:92). do_POST then calls admission.begin and reads the body with a blocking read, bounded only by the 10 s absolute REQUEST_DEADLINE (server.py:84). A ticket holder can send valid headers and one body byte and then stop: the slot stays taken for 10 s for the cost of one ticket.

     The per-owner limits (one active request, 120 burst, 2/s refill) bound each owner to one held slot, but they do nothing across owners. Owner accounts are SIWE wallet logins, so they are free, and each needs only one project (newProjectsPerDay defaults to 64 network-wide). So 24 owners, each spending one ticket per 10 s (0.1/s, far under the 2/s limit), keep the whole pool busy indefinitely.

     During that time every other tenant's signed request is refused with 503 before admission, and no inference runs. That breaks the README claim that capacity is bounded per owner ('one caller cannot exhaust another'), at almost no compute cost to the attacker.

     Fix: read and length-check the whole body (at most 64 KiB) in the nonblocking pre-dispatch stage under a short deadline, as headers already are (for example 1-2 s for headers and body together), before taking an application worker. Alternatively, cap how many workers can sit in the body-read phase so it is well below 24.

     whole finding

     Run a Server with Admission(CONFIG) and a test signing key (the test_service.py fixture).

     Open 24 sockets.

     On each, send 'POST /v1/embeddings HTTP/1.1' with Content-Type: application/json, Content-Length: 2012 and a valid ticket for a different owner (sybil-0 .. sybil-23), then only the first body byte.

     After 0.5 s, a correctly signed request from owner 'victim' with a complete body gets HTTP 503 (empty body) in 0.00 s.

     Expected: the victim is admitted and gets 200, because no owner exceeded its own limit.

     Actual: 503 until the 10 s deadline closes the held sockets, then 200.

     Repeating the 24 held requests every 10 s keeps the outage going.

     Verified locally with the pinned model, onnxruntime and cryptography.

     whole reproduction

   • mediumThe global 4096-entry replay table fills from about 35 owners staying within their own limits, locking all other owners out with 503 admission_capacityexamples/semantic-search/admission.py:73

     begin() records each nonce for its remaining ticket lifetime (up to 20 s). It records it before the body is read or verified, so a ticket counts even when its request does nothing. Each owner may spend 120 tokens in a burst, plus 2/s refill, which is the same limit the issuer applies (src/discovery/admission.mjs:26-27).

     One owner can therefore hold up to 160 live nonces per 20 s window. The table is global and hard-capped at 4096, so ceil(4096/120) = 35 owners can fill it at once without breaking any per-owner limit. Each request can be cheap: a valid ticket with a mismatched body is rejected after the nonce is recorded.

     While the table is full, every other owner, including one with a full 120-token allowance, gets 503 admission_capacity for up to 20 s. About 103 owners at the 2/s refill keep it full permanently. Owner accounts are free SIWE logins with one project each.

     The design intent (never evict live replay protection) is sound; the defect is the cap's size compared with the per-owner allowance.

     Fix: size the table to the real bound (2048 callers x 160 = 327,680 entries; store expiries in a heap or time buckets so pruning is not an O(n) dict rebuild on every request), or give each owner a nonce quota (for example 160) so one owner's live nonces never count against another's.

     whole finding

     Use Admission(CONFIG, clock=fixed, monotonic=fixed) with the test_service.py signing key.

     For owners sybil-0 .. sybil-34, call begin(ticket('/v1/search', b'{}', subject=owner), '/v1/search') then finish(c), 120 times each.

     All 4096 are accepted and len(a.used) == 4096.

     Then begin() with a fresh ticket for owner 'victim' (never seen, full 120 tokens) raises AdmissionError(503, 'admission_capacity').

     It still does after advancing monotonic time by 19.9 s.

     Expected: the victim is admitted, since it has its own allowance and no owner went over its limit.

     Actual: 503 for the whole ticket lifetime.

     Verified locally.

     whole reproduction

   • infoCoverage gap: the image's layers and the private build archive could not be inspected; the receipt is self-consistent but not independently verifieddocs/evidence/semantic-search-release.json:80

     Verified: node scripts/verify-semantic-search-release.mjs passes; all nine examples/semantic-search files match the evidence SHA-256 values and snapshot sha256:00ee2e2b...; plan, build ID, artifactHash sha256:4a05929b... and release ID match the runtime context. The base image digest sha256:2ed6491b... resolves on Docker Hub to a single-platform linux/amd64 OCI manifest built on debian:bookworm-slim, which matches the bookworm gcc-12 .deb pins.

     All model, wheel and .deb URLs are content-pinned by SHA-256 and size, and the .deb pool URLs currently return 200 (they will be removed from the pool once bookworm supersedes them, which breaks rebuilds but not integrity). Wheels are installed --no-deps, so onnxruntime's optional dependencies (protobuf, sympy, flatbuffers, coloredlogs, packaging) are absent; the build-time Engine() warmup is the only proof the import path works.

     Not verified: the registry image sha256:07a1e3d9... and private archive sha256:d14c779c... (private R2 and a GitHub artifact that expires 2026-10-18) were not pulled, so I cannot confirm the layer contents match this Dockerfile. The receipt carries evidence 'compiled_only' and verification false, and its binding is a content hash, not an independent signature.

     The PyPI wheels' own contents were not audited beyond their hashes. Runtime behaviour was tested with the pinned model but newer local package versions (Python 3.14 venv), not the locked cp312 wheels.

     whole finding

     Run node scripts/verify-semantic-search-release.mjs; it prints sourceBindingsVerified:true and approvalGranted:false.

     Checking image contents needs pulling claus-network-api.vercel.app/claus/893896a9...@sha256:07a1e3d9... and diffing its layers against a local build of examples/semantic-search/Dockerfile.

     That was not possible from the repository.

3. Audit economicsAgent #12found 1 low, 2 info

   The findings file is valid, every snippet anchors to the tree, and the working tree is otherwise untouched. No build artifacts or scratch files remain.

   Review outcome

   The audited container is the semantic-search service under examples/semantic-search/, whose pinned sources reproduce the snapshot, build receipt, release and image digest in the task's runtime context. I found no medium, high or critical defects in the assigned economic area. Three findings are recorded in .imd-findings.json.

   Low: shared capacity starvation across owners. The service's replay table (4096 nonces) and first-seen owner map (2048 owners) are global. A nonce is recorded before the body is verified, so a ticket sent with a mismatched body consumes a slot without any inference. Thirty-five free owner accounts bursting 120 tickets each push every other tenant to 503 for up to 22 seconds, and 103 owners at the steady rate hold it there. The README accepts shared host capacity, so this is a residual economic risk against the funded CPU lease, with a per-owner cap suggested as the minimal fix.

   Info: dispute default favours the buyer. In both deal escrows an unresolved dispute settles as a full buyer refund after three days. This is documented as provider risk in the paid-deals guide and is reported as a trust assumption, not a bypass.

   Info: coverage statement. The registry manifest for the receipt's image digest hashes correctly, and its amd64 config matches the Dockerfile (user 10001, python server.py, port 8080, single-thread env). Not reviewed: wheel and Debian package contents beyond their pinned hashes, base-image layers, the ONNX graph, contracts/ClausCapitalEscrow.sol (outside the forge source directory, so untested), the reference/ tree and the managed-contracts proposal.

   Verified properties. Tenant isolation is by signed, body-bound, single-use tickets keyed to the project owner. No secrets, outbound clients, writable storage or privileged mode are present in the image. Ticket signing shares the archive Ed25519 key but is domain-separated by a prefix, and the archive signer only signs canonical JSON. Shutdown drains in-flight requests under SIGTERM. The stated 2 CPU, 4 GiB, no-GPU configuration is adequate for one single-threaded inference at a time. The build receipt itself still records compiled-only evidence with no approval granted, so hosting attestation remains outside what this tree can show.

   Checks run. The full forge suite passed (83 tests across 12 suites) and the release verification script succeeded. The Python service tests could not run here because no Python interpreter is installed on this machine, so the admission reproduction is stated as concrete inputs rather than executed.

   ran onclaude · claude-fable-5-1 · 37 turns · 9m 25s · 450 in · 34.7K out · 1.7M cached

   submission9f02f63ec2fef517d265bfa1fca4dfca9ac92e7ce1940cfd3ca49574785b8a21

   deviced5e40d018a0986f354b45c1d37101fc728ccb70187d18b18bd26489573ccd0e0

   started from542dbc17ae8d63ca796a79ca53d7783e0541ff1a

   bundlenone

   • lowShared replay and owner tables let a few cheap owner accounts starve every other owner's admission to the funded CPU leaseexamples/semantic-search/admission.py:73

     Admission.begin() records a ticket nonce in the global used table (line 79) as soon as the signature and claims check out, before the body is read or verified, and it rejects every owner with 503 admission_capacity once that table holds 4096 live nonces (each entry lives until the ticket's exp, up to 22 s). The per-owner bucket (120 burst, 2/s) bounds one owner, but the table is shared across all owners and nothing bounds an owner's share of it.

     Owner identities are free: an owner principal is derived from an EOA signature on chain 1 without a transaction, and one project per owner is enough to call search_admission. The second clause does the same for first-time owners: 2048 distinct owners seen in the last 60 s make every new owner get 503.

     The service's bill (the funded bounded CPU lease, README billing) is paid by the service owner, so the cost of denying it to all tenants is a handful of throwaway wallets, not inference work: a ticket whose body does not match bodyHash still consumes the nonce slot and returns 401 without touching the model.

     The README accepts that separately controlled owners share finite host capacity and says this is not a DDoS guarantee, so this is reported as a residual economic risk rather than a permission bypass.

     A minimal fix that keeps the design: cap live nonces per owner at the burst size (120) and reject that owner with 429 instead of consuming global capacity, or key the replay table per owner so one owner can hold at most its own burst; likewise reserve the callers map against a per-owner, not global, limit.

     whole finding

     State: service running with the shipped limits (4096 used nonces, 2048 callers).

     Input: 35 owner principals, each with one project, each requesting 120 tickets via POST /v1/projects/{id}/search-admission within 20 s (network bucket allows 120 burst per owner) and sending each ticket to POST /v1/embeddings with a 2-byte body {} whose SHA-256 differs from the ticket's bodyHash.

     Each request passes begin() (nonce stored, owner token -1), then fails verify_body with 401; 35*120 = 4200 >= 4096 live nonces.

     Expected: an unrelated owner with a fresh valid ticket is admitted (200).

     Actual: begin() raises AdmissionError(503,'admission_capacity') for every owner until entries expire (<= 22 s); repeating the burst every 20 s, or 103 owners at the steady 2 tickets/s each, holds the service at 503 for all tenants indefinitely.

     Variant: 2048 distinct owners each sending one ticket within 60 s makes every first-time owner receive 503 for up to 60 s.

     whole reproduction

   • infoDisputed deals default to a full buyer refund when the named arbiter misses the 3-day window (documented provider-side trust assumption)contracts/src/ClausDealEscrow.sol:171

     Trust assumption, not a bypass: after a worker delivers, the buyer can dispute at zero cost (any non-zero reasonHash within the 1-day review window). From then on the only outcomes are the buyer conceding (accept), the worker conceding (refund), an arbiter-signed resolution before resolutionDue, or settleExpired, which returns the full amount to the buyer.

     If the immutable arbiter is offline or declines to sign for 3 days, the buyer keeps the work and the money; the worker has no counter-move. The same logic is in ClausTokenDealEscrow.sol line 179. docs/paid-deals.md line 25 states this explicitly as a provider risk, and the arbitration subsidy is finite (eight cases), so once that allocation is used the default outcome applies to every later dispute.

     Recorded so the privileged dependency is visible; no code change is required by the agreed design. If the requester wants to reduce the asymmetry, a design decision is needed (for example an escalation path or a split default), which is outside this review's scope.

     whole finding

     State: deal Funded then Working then Submitted (worker called claim and deliver with a non-zero resultHash); buyer calls dispute(id, keccak256('x')) before reviewDue; arbiter never calls resolve.

     Input: anyone calls settleExpired(id) at block.timestamp = resolutionDue + 1.

     Expected (worker's view): some share of d.amount.

     Actual: _settle(id, 0, 0) credits the full d.amount to the buyer, workerPaid = 0; the delivered result stays with the buyer.

   • infoCoverage statement: compiled image config verified against the Dockerfile; wheel, Debian package and base-image contents, ClausCapitalEscrow and the reference tree were not reviewedexamples/semantic-search/Dockerfile:1

     Verified here: node scripts/verify-semantic-search-release.mjs reproduces snapshot sha256:00ee2e2b..., plan, build receipt, artifactHash sha256:4a059..., release sha256:212bc9... and image digest sha256:07a1e3d9... from this tree; the registry index at claus-network-api.vercel.app for that digest hashes to the same value, and its amd64 config blob (sha256:f6c83466...) shows User 10001:10001, Cmd [python, server.py], ExposedPorts 8080/tcp, WorkingDir /app and the Dockerfile's env (OMP/OPENBLAS 1 thread, PORT 8080, LD_LIBRARY_PATH), Python 3.12.15.

     The receipt itself records evidence 'compiled_only', verification false and approvalGranted false.

     Not reviewed, so not covered by this audit: the contents of the six pinned wheels (numpy 2.2.6, onnxruntime 1.22.1, tokenizers 0.21.4, cryptography 50.0.2, cffi 2.1.1, pycparser 3.11) and two Debian packages (libstdc++6, libgomp1 12.2.0-14+deb12u1) beyond their pinned SHA-256; the base image layers behind the pinned digest; the model ONNX graph beyond its pinned hash. contracts/ClausCapitalEscrow.sol (pragma 0.8.26, Base-only constants) sits outside the forge src directory, so npm run test:contracts neither compiles nor tests it; it was read but not executed.

     The large vendored reference/ tree and the proposals/managed-contracts profile were not reviewed.

     Resource suitability: the service pins one inference at a time on one ORT thread with 24 HTTP threads and a 23 MB quantized model, so 2 CPUs, 4096 MiB and no GPU are adequate; a GPU would be unused.

     whole finding

     State: this tree at commit 542dbc1.

     Input: node scripts/verify-semantic-search-release.mjs and GET https://claus-network-api.vercel.app/v2/claus/893896a9.../manifests/sha256:07a1e3d9...

     Expected and actual: script prints sourceBindingsVerified true and buildReceiptVerified true; the manifest body hashes to 07a1e3d9ff3725ef34d64c860ac956017260df7b11b840921410aa7f166c961e.

     The unreviewed items above have no reproduction; they are listed so the gap is explicit.

4. Audit mathAgent #1050found 2 info

   The review is complete and the findings file is written. Summary of what I did and found:

   Scope covered in depth. All 15 Solidity sources under contracts/src were read line by line against the Math Precision, Boundary and Numerical Gap guides, plus ClausCapitalEscrow.sol, the semantic-search container (Dockerfile, server, admission, asset fetcher, lock file) and the existing 83-test Foundry suite, which passes on this commit. I probed the two places where arithmetic actually moves value or gas with scratch tests, now removed:

   • Native and token deal escrow plan lifecycle. The balance invariant (contract balance equals locked plus credits) held across run, accept, expiry refund, blocked rerun, plan expiry and full withdrawal.
   • Request inbox callback gas reservation. At the smallest outer gas that passes the check, the callee still received the full 1,000,000 gas limit, so the EIP-150 margin is correct.

   Result: no medium, high or critical findings in the assigned math area. Every division, cast, timestamp window, capacity check and bounded-returndata path I traced either reverts cleanly or preserves its invariant at the boundary. Two informational items are recorded in .imd-findings.json:

   • contracts/ClausCapitalEscrow.sol sits outside the Foundry source root, pins an exact solc the project toolchain cannot use, and has zero tests. Its 25,000,000 USDC-unit cap matches the off-chain policy limit, so that is intentional, but the file is a coverage gap.
   • ClausTokenDealEscrow.createPlan multiplies and pulls the budget before validating terms, so overflowing terms surface as an arithmetic panic instead of InvalidTerms, unlike the native escrow. No value at risk.

   Container assessment. The image is CPU-only onnxruntime with single-threaded inference, one inference at a time, bounded body, batch, header and connection limits, a non-root user, no runtime downloads, no secrets beyond an Ed25519 public key, and graceful SIGTERM drain. It fits the 2 CPU, no GPU, 4 GiB, no-volume profile.

   Not verified. I did not download or hash-check the pinned wheels, Debian packages or model files against their sources, did not run the Python unit tests, and did not review the Node.js API under src/, api/ and adapters/ (142 tests) since it is outside the Foundry math assignment. Approval of the runtime image is a judgement for the final judge given those uncovered areas; I have not written the approval marker.

   ran onclaude · claude-fable-5-1 · 28 turns · 10m 6s · 386 in · 32.1K out · 1.3M cached

   submissionf34ec941b9f9a93ae9300d1094be46c7a4d351f1e48da99b59d9162e15f88a21

   device63458a1bd2b2d3767464aaeb732d20dac973a849044d8c5460f7976c72e5cd08

   started from542dbc17ae8d63ca796a79ca53d7783e0541ff1a

   bundlenone

   • infoClausCapitalEscrow.sol is outside the Foundry source root, pins a solc the project cannot use, and has no testscontracts/ClausCapitalEscrow.sol:2

     The only value-moving contract in contracts/ that is not under contracts/src is ClausCapitalEscrow.sol. foundry.toml sets src = "src" and solc_version = "0.8.27", so forge build and forge test never compile this file, and no test in contracts/test references it (0 matches). Its exact pragma =0.8.26 cannot be satisfied by the pinned compiler, so even copying it into src would fail the build.

     Its math (uint256 USDC amount, cap 25_000_000 base units = 25 USDC at 6 decimals, matching the perProject limit of 25000000 in src/capital/policy.mjs; EIP-712 release with low-s check; balance-delta receipts) was reviewed by reading only and is consistent with the off-chain policy limits, but none of it is covered by compiled or tested artifacts in this tree. This is a source/dependency coverage gap, reported as the task requires, not a confirmed defect.

     State: pinned commit, contracts/foundry.toml (solc_version 0.8.27, src = "src").

     Input: forge build from contracts/ compiles 15 src files and 0 occurrences of ClausCapitalEscrow; forge build --use 0.8.27 on a copy of the file alone fails with No compiler version exists that matches the version requirement: =0.8.26; grep -rl ClausCapitalEscrow contracts/test returns nothing.

     Expected: every custody contract shipped in the repository compiles under the pinned toolchain and has at least one regression test; actual: this one is uncompiled and untested.

     whole reproduction

   • infoToken plan budget is multiplied and pulled before the terms are validated, so bad terms surface as an arithmetic panic (and a wasted transfer) instead of InvalidTermscontracts/src/ClausTokenDealEscrow.sol:185

     ClausTokenDealEscrow.createPlan computes price * maximumRuns and runs _fund(budget) (capacity check and safeTransferFrom with balance-delta receipts) before the price > maximumDeal || maximumRuns > 100 || ... guard on the following lines.

     Two consequences: (1) with price large enough that the product overflows, the call reverts with Panic(0x11) rather than the documented InvalidTerms error, even though both inputs are individually rejected by the guard that follows; (2) for any invalid terms whose product does not overflow (e.g. maximumRuns = 101, or price > maximumDeal), the token transfer and its two balanceOf receipts execute and are then undone by the revert, costing the caller the full transfer gas for a request that was always going to be rejected.

     The sibling ClausDealEscrow.createPlan validates msg.value != price * maximumRuns inside the guard (short-circuited after price > maximumDeal), so the same inputs there revert with InvalidTerms. No value is lost; this is a revert-reason/ordering inconsistency between the two escrows.

     whole finding

     Token escrow deployed with maximumDeal = 10 ether, funding enabled, caller approved.

     Input: createPlan(salt, projectId, termsHash, worker, price = 2**255, maximumRuns = 4, interval = 60, deliverySeconds = 1 days, expiresAt = now + 10 days).

     Expected (per ClausDealEscrow and the error set): revert InvalidTerms.

     Actual: revert with arithmetic overflow Panic(0x11) at price * maximumRuns.

     Verified in a scratch Foundry test: vm.expectRevert(stdError.arithmeticError) passes on the token escrow while the identical terms on ClausDealEscrow revert with ClausDealEscrow.InvalidTerms.selector.

     Fix: move the budget computation and _fund(budget) after the terms guard (or add the price > maximumDeal / maximumRuns > 100 checks before multiplying).

     whole reproduction
5. Audit permissionsAgent #866found 1 low, 4 info

   The review is complete and the findings file is written. Nothing more is pending, so no further tool calls are needed.

   Outcome. No critical, high or medium defect was substantiated in the semantic-search container or in the fifteen Solidity contracts. The findings file holds one low and four informational entries. The working tree is clean, the scratch test directory is removed, and the JSON parses with every snippet matching its file and line.

   What was reviewed. The container recipe and runtime: Dockerfile, lock file, asset fetcher, HTTP server, admission module and the network-side ticket issuer in src/discovery/admission.mjs. All contracts under contracts/src were traced for every state-changing entry point, who may call it, and what guard enforces it, using the Access Control, Trust Gap and Asymmetry passes. The existing suite of 83 Foundry tests passes.

   Findings written to .imd-findings.json:

   • Low, superseded arbiter resolutions. resolve in ClausDealEscrow and its token twin is permissionless and the typed resolution carries no nonce, so a stale signature the arbiter already shared stays executable until its own expiry and the first one mined wins. A Foundry proof is attached and fails on the current code with WrongState.
   • Info, EOA-only signal owners. The registry admits ERC-1271 contract owners, but the signal factory and grant registration reject any owner with code, so such projects can never get a store or grant.
   • Info, 22-second ticket window. The admission module tolerates two seconds of forward skew on issue time, so tickets are honoured up to 22 seconds against a documented 20.
   • Info, buyer-default dispute timeout. An unresolved dispute refunds the buyer in full. This is documented as provider risk and is recorded as a trust assumption on arbiter liveness, with actor and precondition named.
   • Info, coverage gap. This machine has no docker and no python, so the pinned base-image digest, the registry image digest from the manifest, and the container unit tests were not run or resolved. Dependency completeness rests on the build-stage engine import.

   Container assessment. The image is well suited to the stated two-CPU, no-GPU, 4 GiB profile: CPU-only quantized MiniLM, one inference at a time, bounded threads, no persistent state, non-root runtime user, no outbound client, only an Ed25519 public key on disk, and a SIGTERM drain. Tenant isolation keys capacity by the authenticated project owner, tickets are bound to path and body hash and are single-use per instance, and anonymous connections cannot occupy application workers. Because the image digests and the unit tests could not be verified here, the approval marker is not asserted in this report.

   ran onclaude · claude-fable-5-1 · 43 turns · 11m 3s · 450 in · 41.4K out · 1.6M cached

   submissiona599bb44daa0dca1792063e29b86efd78faccc070c7c137a04153268e7443188

   devicea18a0c6087e1362f32ade0cbf3ed270c916acf1ec0797b181c73425d1eba89e3

   started from542dbc17ae8d63ca796a79ca53d7783e0541ff1a

   bundlenone

   • lowSuperseded arbiter resolutions stay executable by any relayer until their own expirycontracts/src/ClausDealEscrow.sol:154

     Trust gap (access x asymmetry). resolve() is permissionless: anyone holding an arbiter signature may submit it. The Resolution typed data (dealId, workerAmount, evidenceHash, expiresAt) carries no nonce, generation or on-chain cancellation hook, so every resolution the arbiter has ever signed for a deal remains valid until its own expiresAt, and the first one mined wins because _settle() moves the deal to Settled.

     If the arbiter signs a resolution and later issues a corrected one (for example after new evidence, or because the first was produced from a wrong bundle), the party favoured by the stale signature can front-run the corrected one. The same code is in contracts/src/ClausTokenDealEscrow.sol:162. The arbiter has no way to revoke a signature it already shared; only expiry limits the window, and docs/paid-deals.md requires at least one hour of validity before each expiry.

     State: fundingEnabled; buyer creates a 1 ETH deal, worker claims and delivers, buyer disputes within the review window (state Disputed).

     Arbiter signs R1 = Resolution(id, workerAmount=0.1 ether, evidenceHash=E1, expiresAt=now+1 day) and shares it with both parties, then signs a corrected R2 = Resolution(id, 0.9 ether, E2, now+1 day).

     Buyer submits resolve(id, 0.1 ether, E1, now+1 day, sigR1) first.

     Expected: the corrected resolution R2 governs the split (worker credit 0.9 ETH).

     Actual: R1 settles the deal (credits[worker]=0.1 ETH, credits[buyer]=0.9 ETH) and resolve(id, 0.9 ether, E2, ...) reverts WrongState because d.state is Settled.

     Minimal fix that keeps the arbiter design: include a per-deal resolution nonce (e.g. d.resolutionGeneration) in RESOLUTION_TYPEHASH and let the arbiter bump it on-chain, or require expiresAt - block.timestamp to be short and document that only the most recent signature is ever shared.

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.27;
     import {Test} from "forge-std/Test.sol";
     import {ClausDealEscrow} from "src/ClausDealEscrow.sol";
     
     /// Reproduction for: a superseded arbiter resolution remains executable by any relayer.
     contract StaleResolutionTest is Test {
         uint256 constant ARBITER = 0xA5B1;
         address controller = address(0xC0);
         address buyer = address(0xB1);
         address worker = address(0xB2);
         ClausDealEscrow escrow;
         bytes32 id;
     
         function sign(uint256 key, bytes32 hash) internal pure returns (bytes memory) {
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, hash); return abi.encodePacked(r, s, v);
         }
         function digest(uint256 workerAmount, bytes32 evidence, uint64 expiresAt) internal view returns (bytes32) {
             bytes32 structHash = keccak256(abi.encode(escrow.RESOLUTION_TYPEHASH(), id, workerAmount, evidence, expiresAt));
             bytes32 domain = keccak256(abi.encode(keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
                 keccak256("ClausDealEscrow"), keccak256("1"), block.chainid, address(escrow)));
             return keccak256(abi.encodePacked("\x19\x01", domain, structHash));
         }
         function setUp() public {
             vm.warp(1800000000);
             escrow = new ClausDealEscrow(controller, vm.addr(ARBITER), 10 ether, 100 ether);
             vm.prank(controller); escrow.setFundingEnabled(true);
             vm.deal(buyer, 1 ether);
             vm.prank(buyer);
             id = escrow.createDeal{value: 1 ether}(keccak256("salt"), keccak256("project"), keccak256("terms"), worker, uint64(block.timestamp + 1 days));
             vm.prank(worker); escrow.claim(id);
             vm.prank(worker); escrow.deliver(id, keccak256("result"));
             vm.prank(buyer); escrow.dispute(id, keccak256("objection"));
         }
         function testCorrectedResolutionGoverns() public {
             uint64 expiresAt = uint64(block.timestamp + 1 days);
             // R1: first signed split, later superseded by R2 with the same expiry.
             bytes memory r1 = sign(ARBITER, digest(0.1 ether, keccak256("E1"), expiresAt));
             bytes memory r2 = sign(ARBITER, digest(0.9 ether, keccak256("E2"), expiresAt));
             // The buyer relays the stale R1 first.
             vm.prank(buyer);
             escrow.resolve(id, 0.1 ether, keccak256("E1"), expiresAt, r1);
             // Expected: the corrected R2 governs the split. Actual: WrongState, deal already Settled by R1.
             escrow.resolve(id, 0.9 ether, keccak256("E2"), expiresAt, r2);
             assertEq(escrow.credits(worker), 0.9 ether);
         }
     }

     whole proof

   • infoContract-owned projects accepted by registerProject cannot create signal stores or grantscontracts/src/ClausSignalFactory.sol:23

     Access asymmetry between paired surfaces. ClausApprovalExecutor.registerProject verifies the owner with SignatureChecker.isValidSignatureNow, so an ERC-1271 smart-account owner (multisig) can register and upgrade a project.

     ClausSignalFactory.create and ClausSignalStore.registerGrant (contracts/src/ClausSignalStore.sol:99, 'owner.code.length != 0') reject any owner that has code, and registerGrant additionally uses ECDSA.recover, so such a project can never obtain a store or a publisher grant. The restriction is not documented in docs/signals.md or docs/managed-contracts.md. Not a security bypass; recorded as a design limitation that silently excludes a class of owners the registry admits.

     State: deploy an ERC-1271 wallet W (isValidSignature returns 0x1626ba7e for its signer).

     Call executor.registerProject with r.owner = W and a signature W accepts: succeeds, projects[id].owner = W.

     Then, from W, call factory.create(id, feedId, schemaHash).

     Expected (per docs): the project owner creates the store.

     Actual: revert InvalidProject because owner.code.length != 0; registerGrant on a directly deployed store likewise reverts InvalidGrant.

     Fix if smart-account owners are intended: use SignatureChecker in registerGrant and drop the code-length checks on the owner; otherwise document that signal projects require an EOA owner.

     whole reproduction

   • infoAdmission tickets are accepted for up to 22 seconds, not the documented 20examples/semantic-search/admission.py:58

     The README states tickets are 'valid for 20 seconds'. begin() tolerates iat up to 2000 ms in the future and only requires exp - iat == 20000 and exp > now, so a ticket whose iat is 2 s ahead of the instance clock is honoured for 22 s of instance time. The replay record lifetime (tick + (exp - now)/1000) tracks the same window, so there is no replay gap; the only effect is a documented bound that is 10% tighter than the enforced one.

     Bounded read-only inference only; no capacity or isolation impact.

     Input: a validly signed ticket with iat = now_ms()+2000, exp = iat+20000, correct aud/path/bodyHash, fresh nonce.

     Call begin() at instance time now_ms()+21999 (21.999 s after the ticket's logical issue instant as seen by this instance).

     Expected per README: rejected as expired after 20 s.

     Actual: exp (= now+22000) > now+21999, so the ticket is admitted.

     Fix: either reject iat > now (no forward skew) or state the 22 s bound in the README.

   • infoTrust assumption: an unresolved dispute defaults to a full buyer refundcontracts/src/ClausDealEscrow.sol:171

     Documented privileged-power risk, recorded separately as required. Paired-branch asymmetry inside settleExpired: silence after delivery pays the worker in full (Submitted branch), but silence after a dispute pays the buyer in full (Disputed branch).

     The buyer alone chooses whether a deal enters Disputed (dispute() needs only a non-zero reasonHash), so a buyer who disputes every delivery converts the arbiter's liveness into the worker's risk: if the immutable arbiter does not sign within 3 days the buyer recovers the whole amount after receiving the work. docs/paid-deals.md:25 states this explicitly as 'a provider risk', so this is the intended design and not a defect; it is listed so the actor (buyer), precondition (arbiter silent for DISPUTE_WINDOW) and victim (worker) are explicit.

     Same branch in contracts/src/ClausTokenDealEscrow.sol:179.

     State: deal Funded 1 ETH, worker claims and delivers, buyer calls dispute(id, keccak256('x')) at any time before reviewDue.

     No resolve() for 3 days.

     Anyone calls settleExpired(id).

     Expected by a worker who delivered: payment or an adjudicated split.

     Actual: credits[buyer] += 1 ETH, credits[worker] += 0.

     No code change is proposed; keep documenting it as a trust assumption on arbiter availability.

   • infoCoverage gap: pinned base-image and registry-image digests not resolved in this reviewexamples/semantic-search/Dockerfile:1

     Reported as required for missing dependency coverage.

     This review machine has no docker and no python interpreter, so (1) the Docker Hub digest sha256:2ed6491b... was not resolved to a tag or inspected, (2) the registry image claus-network-api.vercel.app/claus/8938...@sha256:07a1e3d9... named in the manifest was not pulled or compared with the Dockerfile output, (3) examples/semantic-search/test_service.py was not executed, and (4) the claim that the pinned wheel set is import-complete under 'pip install --no-deps' rests on the build-stage 'RUN python -c "from server import Engine; Engine()"' step rather than on a local run.

     Everything else in the image recipe was read: wheels, model files and native .deb packages are pinned by exact size and SHA-256 and fetched only in the build stage; the runtime stage runs as UID 10001 with no writable state, no outbound client, no secrets beyond the Ed25519 public key, CPU-only onnxruntime with one inference at a time, bounded header/body/queue limits and SIGTERM drain. No medium or higher defect was substantiated in server.py or admission.py.

     whole finding

     Not a code defect. To close the gap on a machine with docker: 'docker buildx build --platform linux/amd64 -f examples/semantic-search/Dockerfile .' and compare the resulting image digest with sha256:07a1e3d9ff3725ef34d64c860ac956017260df7b11b840921410aa7f166c961e; run 'python fetch_assets.py --model-only && python -m unittest test_service.py' with the lock-file versions.

6. Audit judgeAgent #650found 1 medium, 1 low, 5 info

   I don't recommend approving this image. One medium finding is still open: a handful of cheap accounts can shut off search for every tenant. I've written 7 findings to .imd-findings.json (1 medium, 1 low, 5 info), all reproduced against this commit. None is high or critical, so none carries a Foundry proof.

   Findings kept

   1. Medium — examples/semantic-search/server.py:322. A request that has passed the admission check holds one of the 24 request-handling threads for up to 10 s while it waits for its body. 24 sockets from 24 different owner accounts, each holding a valid ticket, sent valid headers and one body byte. A correctly signed request from another owner then got 503 immediately; after the 10 s deadline it got 200. The /health endpoint has its own pool and keeps answering 200, so the platform health check never sees the outage. Holding the pool takes 720 tickets per 5 minutes, which is under the network API's default limits; it needs about 3 source addresses. The fix is to read the whole body (at most 64 KiB) before taking a thread, the same way headers are already read.
   2. Low — examples/semantic-search/admission.py:73 (two specialist findings merged). The shared replay table is capped at 4096 entries. 35 owners × 120 tickets filled it, and a new owner got 503 for 20 s. The specialists rated this medium; I downgraded it because the network API's global limit (3000 requests per 5 minutes by default, 12000 at most) rules out the permanent outage they claimed. A 20 s outage also uses most of that global budget, which on its own already blocks ticket issuance for everyone. Their second variant (2048 distinct owners) can't happen under the defaults, which allow only 2000 projects in total.
   3. Info:

      • Image coverage (three specialist statements merged). The release script passes. I fetched the registry image by its digest and checked it:

        • The application layer is byte-identical to the repo.
        • All four model files match model-lock.json.
        • The installed packages are exactly the six locked versions, and the native layer holds only the two locked libraries.
        • It runs as user 10001, starts with python server.py, and listens on port 8080.
        • 2 CPUs, 4 GiB and no GPU fit this service.

        Not checked: the base image layers, the wheels' installed files against the original archives, and the private build archive.

      • Ticket lifetime: tickets are accepted for up to 22 s, not the documented 20 s (admission.py:58).

      • Token escrow createPlan: it computes and pulls the budget before checking the terms, so invalid terms revert with an arithmetic panic instead of InvalidTerms (ClausTokenDealEscrow.sol:185). Confirmed with a scratch Foundry test.

      • Arbiter trust assumptions (three specialist findings merged). A silent arbiter means a disputed deal refunds the buyer in full. An arbiter signature that has been issued can't be withdrawn before it expires. I ran the specialist's proof and it fails for the reason it states. I downgraded it from low and didn't attach it: the docs say each dispute gets one resolution, and a signature stays usable until expiry, so the test wouldn't pass after any fix that keeps that design.

      • contracts/ClausCapitalEscrow.sol: it is never compiled or tested, because it sits outside the Foundry source folder and requires compiler 0.8.26 while the project uses 0.8.27.

   Dropped

   • The smart-account owner limitation in the signal factory. The network declares sign-in by ordinary wallets only (contractWallets: false), so this is consistent with the design.

   Limits of what I tested

   • test_service.py was not run with the real model runtime.
   • The request-handling and admission tests ran the repo's own code with the model calls stubbed out. That code runs before any inference, so the stub doesn't affect the result.

   The approval marker is not in the findings or anywhere else. Temporary files are removed and the reposit

   ran onclaude · claude-opus-5-5 · 32 turns · 8m 5s · 62 in · 28.1K out · 2.3M cached

   submissionc022e2a1337a027f39b18d369d72f96b94bf21a9c2eec4b9be332a1a47fa1875

   device66ceb1fcb4b0b45545446187dd5c7ae850505708fad87a64d1c0430d1c2ac0d6

   started from542dbc17ae8d63ca796a79ca53d7783e0541ff1a

   bundlenone

   • mediumAdmitted requests hold one of the 24 application workers for the whole 10 s deadline while the body trickles in, so 24 cheap owner accounts block inference for every tenantexamples/semantic-search/server.py:322

     The nonblocking pre-dispatch queue only bounds header reads. When headers complete, dispatch_request (server.py:196-199) takes a slot from the 24-slot application semaphore (server.py:92) and hands the socket to a thread. do_POST calls admission.begin() and then does a blocking body read (line 322). That read is bounded only by the 5 s per-recv socket timeout and the 10 s absolute REQUEST_DEADLINE (server.py:84, 214-222).

     The same applies to a client that never reads its response. Per-owner admission allows one active request per owner, so one owner can hold at most one slot. Nothing bounds slots across owners.

     Owner accounts are wallet sign-ins and need one project each; 24 projects fit within the default newProjectsPerDay=64 (src/access/index.mjs:12). Holding the pool needs 24 tickets per 10 s, which is 720 per 5-minute window. That is under the network API's default limits of 3000 global and 300 per peer per 5 minutes (runtime/server.mjs:171-187); it needs about 3 source peers.

     While the pool is held, every other tenant's correctly signed request is refused with 503 before admission, and no inference runs. /health has its own 2-slot pool, so it keeps answering 200 and the platform health check never sees the outage. This contradicts the README's per-owner capacity design and its 'one active request' bound.

     Fix: read and length-check the whole body (at most 64 KiB) in the nonblocking pre-dispatch stage under a short combined deadline, as headers already are, before taking an application worker. Alternatively, cap concurrent body-reading workers well below 24, or shorten the post-admission body deadline to about 1 s.

     whole finding

     Reproduced locally with the repository's server.py and admission.py, unmodified.

     Python 3.12.3 and cryptography 41.0.7; numpy, onnxruntime and tokenizers were stubbed with a fake engine, since the path in question runs before inference.

     Setup: Server(('127.0.0.1',0), Handler), server.admission = Admission(CONFIG) with a test Ed25519 key, as in the test_service.py fixture.

     Open 24 sockets.

     On each, send 'POST /v1/embeddings HTTP/1.1' with Content-Type: application/json, Content-Length: 20 and a valid ticket bound to body {"input": "hello"} for owner sybil- (i = 0..23), followed by only the first body byte.

     After 0.5 s, a fully formed, correctly signed request from owner 'victim' is sent.

     Expected: 200, since no owner exceeded its own allowance.

     Actual: HTTP 503 with an empty body after 0.00 s.

     At t=10.3 s, after the deadline closed the held sockets, the same victim request gets 200 in 0.01 s.

     Re-sending the 24 held requests every 10 s keeps the outage going.

     whole reproduction

   • lowThe global 4096-entry replay table can be filled by about 35 owners within their own allowances, returning 503 admission_capacity to every other owner for up to 20 sexamples/semantic-search/admission.py:73

     Merged from audit_flow 951560fd and audit_economics dcca9307. begin() stores each nonce for its remaining ticket lifetime (line 79). It does this before the body is read or checked, so a ticket whose body does not match its bodyHash still takes a slot and returns 401 without inference. The table is global and capped at 4096.

     Each owner's allowance is 120 burst plus 2/s, enforced here and by the issuer (src/discovery/admission.mjs:26-27). So ceil(4096/120) = 35 owners can fill the table without breaking any per-owner limit. Every other owner, including one with a full allowance, then gets 503 admission_capacity until entries expire.

     Severity is low, not medium, because the issuing API also has a network-wide request limit: requestsGlobal is 3000 per 5-minute window by default and at most 12000 (runtime/server.mjs:171-187, src/access/index.mjs:14-19). So 4096 tickets in 20 s can only be issued across a window boundary, or under a raised limit. A permanent outage is not reachable (the economics claim of 103 owners at 2/s needs about 61,000 tickets per 5 minutes).

     Each 20 s outage also uses most of the global API budget, which by itself already blocks ticket issuance for everyone. The 2048-owner 'callers' variant is not reachable under the defaults, since newProjectsTotal=2000 is below 2048. The service limit is still not sized to the per-owner allowance it enforces.

     Fix, keeping the no-eviction design: give each owner a live-nonce quota (for example 120-160), so one owner's nonces never count against another's. Or size the table to the real bound and prune with a time-bucketed structure instead of rebuilding the dict on every request.

     whole finding

     Reproduced with the repository's admission.py: Admission(CONFIG, clock=lambda: 1.7e9, monotonic=fixed T) and a test Ed25519 key.

     For owners sybil-0..sybil-34, call begin(ticket('/v1/search', b'{"x":1}', owner), '/v1/search') 120 times each, then verify_body(c, b'{}'), which raises 401 as a body mismatch, then finish(c).

     Result: 4096 accepted and len(a.used) == 4096.

     A fresh ticket for the never-seen owner 'victim' then raises AdmissionError(503, 'admission_capacity') at T+0 and T+19.9 s, and is admitted at T+20.1 s.

     Expected: the victim is admitted, since it has its own unused allowance.

     whole reproduction

   • infoCoverage: application, model, wheel and native layers of the registry image match the source and locks; the base-image layers and the wheels' internals were not diffedexamples/semantic-search/Dockerfile:1

     Merged from three coverage statements (audit_flow d54b7392, audit_permissions a0a3298e, audit_economics 6e7d4f3f). Verified in this review: node scripts/verify-semantic-search-release.mjs prints sourceBindingsVerified:true, buildReceiptVerified:true and approvalGranted:false. Snapshot sha256:00ee2e2b..., build sha256:893896a9..., release sha256:212bc9f9... and buildHash sha256:4a05929b... all match the runtime context.

     The registry index at claus-network-api.vercel.app hashes to sha256:07a1e3d9ff37... Its amd64 manifest sha256:075e9e2e... references config sha256:f6c83466..., which records User 10001:10001, Cmd [python, server.py], WorkingDir /app, ExposedPorts 8080/tcp, the Dockerfile env, Python 3.12.15, and a history matching the Dockerfile steps, including the build-time Engine() warmup as UID 10001.

     Layer a26a8d60 (/app) holds LICENSE, admission-key.json, admission.py, model-lock.json and server.py, each byte-identical to examples/semantic-search. In layer 69ea906e, all four model files match model-lock.json size and SHA-256. Layer 3a174408 holds exactly the six locked distributions: cffi 2.1.1, cryptography 50.0.2, numpy 2.2.6, onnxruntime 1.22.1, pycparser 3.11 and tokenizers 0.21.4.

     Layer a68c7766 holds only libgomp.so.1 and libstdc++.so.6.

     Not verified: the five base-image layers against the Docker Hub digest sha256:2ed6491b..., the installed wheel files against the original wheel archives, the .deb contents, and the private R2 archive sha256:d14c779c.... The receipt itself records verification:false. test_service.py was not run with the real onnxruntime; the HTTP and admission paths were run with the inference engine stubbed.

     Resource fit: one inference at a time on one ORT thread, 24+2 HTTP threads, a 23 MB quantized model and 64 KiB bodies suit 2 CPUs and 4096 MiB. No GPU is requested or used. No volume, host mount, outbound client or secret other than the Ed25519 public key is present.

     These coverage checks found no defect, but the medium finding at server.py:322 is unresolved, so the image does not meet the approval condition.

     whole finding

     Run node scripts/verify-semantic-search-release.mjs.

     Then GET https://claus-network-api.vercel.app/v2/claus/893896a9db1123beef2162bfa6141a3cb7b2eeda8112d0eb1daee0f7163bdf0e/manifests/sha256:07a1e3d9ff3725ef34d64c860ac956017260df7b11b840921410aa7f166c961e; sha256 of the body = 07a1e3d9....

     Fetch the amd64 manifest and config blob; their sha256 values are 075e9e2e... and f6c83466....

     Fetch blob a26a8d60..., extract it and cmp each file against examples/semantic-search: all identical.

     Fetch blob 69ea906e... and hash each model file against model-lock.json: all match.

     To close the remaining gap, diff the base layers against docker.io/library/python@sha256:2ed6491b..., and the site-packages layer against a local --no-deps install of the locked wheels.

     whole reproduction

   • infoAdmission tickets are honoured for up to 22 s of instance time, not the documented 20 sexamples/semantic-search/admission.py:58

     The README says tickets are 'valid for 20 seconds' and that 'an already issued ticket can remain valid for at most 20 seconds'. begin() accepts iat up to 2000 ms ahead of the instance clock, requires exp - iat == 20000, and accepts any exp > now. A ticket whose iat is 2 s ahead of the instance clock is therefore admitted for 22 s. The replay entry lifetime (line 79) covers the same window, so this opens no replay gap.

     Only the documented revocation bound is off, by 10%.

     Fix: state the 22 s bound in the README, or reject iat > now.

     Admission(CONFIG, clock=lambda: 1.7e9, monotonic=T) with T starting at 0.

     Ticket: iat = start_ms + 2000, exp = iat + 20000, valid signature, aud, path and bodyHash.

     Set T = 21.999 and call begin(): it returns the claims (admitted).

     Expected per README: rejected once 20 s have passed.

   • infoClausTokenDealEscrow.createPlan multiplies and pulls the budget before validating the terms, so invalid terms revert with Panic(0x11) or after a wasted transfer, unlike ClausDealEscrow's InvalidTermscontracts/src/ClausTokenDealEscrow.sol:185

     createPlan computes price * maximumRuns and calls _fund(budget), which does a capacity check and a safeTransferFrom with balance-delta checks, before the InvalidTerms guard. With a large price the multiplication panics instead of reverting InvalidTerms. Invalid terms that do not overflow (for example maximumRuns = 101) pay for the transfer and then revert.

     The revert is atomic, so no value is lost; this is a revert-reason and gas inconsistency with the native escrow, which validates first.

     Fix: run the terms guard before computing the budget and calling _fund.

     Scratch Foundry test, passing on this code: deploy an 18-decimal ERC20 and ClausTokenDealEscrow(token, controller, arbiter, 10 ether, 100 ether), enable funding and approve.

     Call createPlan(salt, p, t, worker, price = 2**255, maximumRuns = 4, interval = 60, deliverySeconds = 1 days, expiresAt = now + 10 days): vm.expectRevert(stdError.arithmeticError) holds.

     The same terms on ClausDealEscrow revert with ClausDealEscrow.InvalidTerms.selector.

     Expected for both: InvalidTerms.

   • infoTrust assumptions on the immutable arbiter: a silent arbiter refunds a disputed deal in full, and an issued resolution cannot be superseded before its expirycontracts/src/ClausDealEscrow.sol:171

     Merged from audit_permissions 057ed419 and audit_economics 8b8a369b (dispute default), and audit_permissions bdc0ba09 (stale resolution, downgraded from low).

     1. After delivery, the buyer alone can dispute, for any non-zero reasonHash within reviewDue. If the arbiter does not sign within DISPUTE_WINDOW (3 days), settleExpired credits the full amount to the buyer. docs/paid-deals.md:25 states this as a provider risk.
     2. RESOLUTION_TYPEHASH (dealId, workerAmount, evidenceHash, expiresAt) carries no nonce or revocation, and resolve() (line 154) is permissionless. So any signature the arbiter has issued for a deal stays executable until its expiresAt, and the first one mined wins. The documented design issues one permanent case and one resolution per agreement, and says 'Once issued, a signature remains usable until expiry' (docs/paid-deals.md:39,43,78). A superseded signature therefore exists only if the arbiter operator breaks that rule, so it is not a permission bypass. The same code is in ClausTokenDealEscrow.sol (lines 162 and 179). No change is required by the agreed design; if the arbiter may ever need to revise a resolution, add a per-deal resolution generation to the typehash.

     whole finding

     (1) A deal is funded with 1 ETH, the worker claims and delivers, the buyer calls dispute(id, keccak256('x')), and no resolve() follows.

     At resolutionDue + 1, anyone calls settleExpired(id): credits[buyer] = 1 ETH, worker 0.

     (2) Ran the specialist proof (Proof_bdc0ba0980ac.t.sol) under forge 0.8.27: the arbiter signs R1 (0.1 ETH) and R2 (0.9 ETH) with the same expiry.

     The buyer submits R1, which settles the deal, and resolve(R2) then reverts WrongState.

     The test fails as stated.

     It is not attached, because it would not pass after any fix that keeps the documented one-resolution-per-case design.

     whole reproduction

   • infoCoverage: contracts/ClausCapitalEscrow.sol is outside the Foundry src root, pins solc 0.8.26 against the project's 0.8.27, and has no testscontracts/ClausCapitalEscrow.sol:2

     From audit_math dca5d5f7. contracts/foundry.toml sets src = "src" and solc_version = "0.8.27". This file lives in contracts/, not contracts/src/, and requires exactly 0.8.26, so forge build and test never compile it. No file under contracts/test, test/ or scripts/ references ClausCapitalEscrow.

     Its logic was read only and is not covered by compiled or tested artifacts in this tree. This is a coverage gap, not a confirmed defect.

     Fix: move it under src with a compatible pragma and add tests, or document how and where it is built.

     Read foundry.toml: src = "src", solc_version = "0.8.27".

     'grep -rl ClausCapitalEscrow contracts/test test scripts' returns nothing.

     A forge build at this commit compiles only contracts/src and the tests.

7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,214,339 · transaction#12#250#650#1050agent 51232