What's new in HiveIQ

Each marketplace task collects parallel bids from all capable providers (capability filter applied first), scores them through a weighted formula, and persists the winning bid plus all losing bids to the marketplace ledger so the dashboard can replay decisions. Successful task completion writes a positive reputation outcome on-chain via the Vitreus pallet_reputation precompile; failures decay the score. Bid collection is timeout-bounded at 200ms so a slow provider can't drag down the auction.

The registry tags every model with structured capability metadata — reasoning, code, math, multilingual, vision, function-calling — alongside per-1K-token pricing and latency profiles. The recommendation endpoint takes a free-text workload description and returns the top 3 models ranked by capability match × cost-efficiency, optionally filtered by max-cost or required-capability constraints.

When a provider registers, HiveIQ verifies their NAC level on-chain and stores the level alongside the provider record. Higher NAC levels (1–4) unlock progressively richer capabilities: Level 1 enables basic task execution, Level 2 unlocks high-priority routing, Level 3 enables TEE workloads, and Level 4 grants the +10% reputation bonus that compounds in marketplace bid scoring.

The decomposer parses the task into a directed acyclic graph of subtasks with explicit dependencies. The orchestrator walks the DAG topologically, dispatching independent steps in parallel batches and serializing dependent ones. Each step emits SSE events (step.start, step.delta, step.complete) so the dashboard renders live. A final synthesis call merges all step outputs into one cohesive response.

The discovery document advertises HiveIQ's capabilities, supported methods, auth requirements, and rate limits in the A2A standard schema. Inbound A2A envelopes are translated into native HiveIQ task and session requests, executed through the same routing engine, and returned in A2A response format. This makes HiveIQ a drop-in compute layer for any A2A-compliant agent framework — including Google Agentspace and the broader A2A ecosystem.

A backend dispatcher (app.db_backend) selects between SQLite and Postgres at startup from DATABASE_URL — SQLite is preserved as a zero-config local-dev fallback, while production runs on Postgres 16 with asyncpg pooling. Schema is idempotent: CREATE TABLE IF NOT EXISTS + ALTER TABLE ADD COLUMN IF NOT EXISTS for every column, so deploys never need a separate migration step.

Hot-path lookups (API key → user resolution, analytics rollups, per-user rate counters) hit Redis with a 5-minute TTL, eliminating repeated database round-trips on every authenticated request. Key revocation deletes the cached entry directly so a revoked key stops authenticating within milliseconds instead of waiting for the TTL to expire. Rate limit counters live in Redis, so they survive process restarts and deploys.

Every JWT carries a jti (JWT ID); logout adds the jti to a Redis blacklist with TTL matching the token's remaining lifetime. The auth middleware checks the blacklist on every request. Password changes bump a per-user password_changed_at timestamp — any token issued before that timestamp is rejected, instantly invalidating every session for the user. Failed login attempts incur a 100ms artificial delay to flatten timing-based user enumeration. API key usage records the source IP for audit.

A logging middleware tags every request with a UUID request_id that propagates through the entire call chain — application logs, the request audit table, and outbound provider calls all share the same id, making cross-system tracing trivial. Email addresses are SHA-256 hashed before being logged. Sentry ingests unhandled exceptions with the request_id attached so reproducing a production incident is a one-click jump from Sentry to the matching access-log row.