Glossary

Many ordinary machines that each run DuckDB and donate a slice of their RAM/CPU to run queries for others.

Impact: You get database compute from a shared pool instead of paying for one big server.

The node that wants a query run. It broadcasts the job and picks which workers to use.

Impact: Anyone can ask the grid to compute something; no central service sits in the middle.

A machine that accepts a job and actually runs the SQL.

Impact: More online workers = more capacity and more redundancy for cross-checking results.

One query execution. The same job is usually sent to several workers at once.

Impact: Running it in several places is what makes a result both fast and verifiable.

Sending the same job to k workers in a race instead of trusting one. The first acceptable answer wins; the slower copies are cancelled (RESET).

Impact: Cuts tail latency (a slow/dead worker can't stall you) and provides copies to compare.

The number of workers whose results must match before an answer is accepted (e.g. 3 of 5).

Impact: A wrong answer from one machine can't win — enough independent machines must agree.

Fast = return the first result and check agreement in the background; Quorum = wait for enough matching results before returning.

Impact: Lets you trade a little latency for a stronger correctness guarantee per query.

How sensitive the data is: Public, Internal, or Sensitive.

Impact: Higher sensitivity automatically routes work to more-trusted, hardware-attested machines.

A pre-flight, metadata-only size estimate decides whether a query runs locally or on the grid; a job that turns out too big (or OOMs) is rerouted to higher-capacity hosts instead of failing.

Impact: Small queries stay free and local; big ones find a machine that can handle them, and only error out when no host in the swarm can.

Non-personal machine-class metadata a host self-reports — CPU model/arch, RAM, disk, OS.

Impact: Feeds analytics and size-based routing as a HINT; it is distinct from the donated compute budget and carries no personal data.

A 0–1 number a requester computes for each worker from its history, vouches, stake, and hardware tier.

Impact: Requesters prefer high-trust workers and skip low-trust ones — so good behavior is rewarded with more work.

A recency-weighted record of how often a worker returned correct results, built from signed receipts.

Impact: Cheating or failing drops R fast; the worker then gets selected less and earns less.

Hardware-trust level. L0 = anonymous laptop, L1 = verified boot (TPM), L2 = confidential enclave (TEE) whose memory even the owner can't read.

Impact: Sensitive data is only sent to L2 hardware; the tier is a hard gate, not just a bonus.

A small signed statement about a finished job's outcome (correct / wrong / timeout).

Impact: Receipts are the portable, tamper-evident history that reputation is built from.

A stable BLAKE3 fingerprint of a result, computed so row order and number formatting don't change it.

Impact: Lets two machines prove they got the identical answer by comparing one short string.

Workers send the fingerprint (hash) of their result before sending the full data.

Impact: Stops a worker from copying others' answers — it must commit to its own result up front.

The requester secretly slips in a query whose answer it already knows.

Impact: Catches cheaters even on non-redundant jobs; a worker that fails is marked wrong and slashed.

Making it costly to spin up many fake identities (via proof-of-work, vouches, and stake).

Impact: Stops an attacker from flooding the grid with fake workers to outvote honest ones.

Quorum is fingerprint-aware: the requester pins an input snapshot and each worker reports an input_fingerprint, so only results computed over the SAME source data are compared.

Impact: A stale, swapped, or drifted data source can't silently win a quorum — agreement now proves same-query AND same-input.

The composite ranking used to pick eligible hosts: quality, reliability-gated stake, price, and counterparty-measured latency, throughput and proven capability.

Impact: Genuinely faster, higher-throughput, proven-capable hosts win dispatch more often — and the scores are measured by counterparties, not self-reported, so they can't be gamed.

A distributed phone book: nodes find each other by ID with no central directory.

Impact: The grid scales to many peers and keeps working as machines come and go.

Nodes periodically broadcast a small 'capability record' (free RAM, price, attestation) to the network.

Impact: Requesters can shop for suitable workers locally without asking a central server.

Tricks (AutoNAT, DCUtR hole-punching, relays) that let machines behind home/office routers connect directly.

Impact: Ordinary computers on different networks can join with no port-forwarding or fixed IP.

Any reachable node you contact once just to enter the swarm.

Impact: Not a central server — it holds no data, is never in the query path, and is freely replaceable.

The [security].mode = private switch that turns the open grid into a fully closed company pool: allowlist mTLS, cryptographic group tokens, a non-default network, fail-closed discovery, and a default-deny requester roster.

Impact: Outsiders can neither connect/impersonate nor be served, and a misconfigured private node fails to start (fail-closed) rather than leaking.

A fast, encrypted internet transport (over UDP) with TLS 1.3 built in and mutual authentication.

Impact: Everything on the wire is private and pinned to each node's identity; nothing is readable in transit.

Bandwidth-Delay Product — how much data should be 'in flight' = bandwidth × round-trip time.

Impact: Sizing the flow-control window to the BDP is what lets a high-latency link reach full speed.

Splitting a large result across several QUIC streams at once.

Impact: Throughput jumps (often roughly doubles) before plateauing — fewer, slower transfers otherwise.

Optionally squeezing result bytes before sending.

Impact: Saves bandwidth on compressible data; usually left off on a fast local network.

Cloud buckets (S3 / Azure / GCS) where the actual data files live, encrypted at rest.

Impact: Workers are pure compute — they never own your data, so a host can't keep it.

A short-lived, read-only key that only unlocks the exact data prefix one job needs.

Impact: Even a malicious worker can read only that slice, briefly — never your whole bucket or long-term keys.

Encrypting the data files themselves so the stored bytes are meaningless without the per-job key.

Impact: At-rest data is safe even if the storage account is exposed.

Money a worker bonds (locks up) as a deposit before doing paid work.

Impact: It's collateral — cheat and you lose it, so honesty is the profitable choice.

A 0–1 score from the stake amount, log-scaled and capped so whales don't dominate.

Impact: More stake slightly raises selection odds, but with diminishing returns (anti-centralization).

Automatically taking part of a worker's stake when it provably misbehaves (wrong result, cheating, downtime).

Impact: Turns bad behavior into a direct financial loss; the penalty is split to challenger/burn/treasury.

The requester locks the maximum price up front in a per-job contract.

Impact: The worker is guaranteed it can be paid, and the requester can never be over-charged.

The escrow only pays out when someone presents the agreed quorum result hash.

Impact: Money is released by the correct answer itself — no trusted operator decides who gets paid.

A small fixed cut (5%) paid to each agreeing non-winner.

Impact: Pays the workers whose matching results formed the quorum — so honest verification is worth doing.

The protocol/admin cut (15%) taken once from a paid job's escrow, enforced on-chain in GlobalParams.

Impact: A fixed, transparent fee — the winner takes the bounded remainder after φ and the κ commissions.

The default metered cost model: cost = per-second rate × processing seconds. A 5× cap is both the billing ceiling and a hard deadline; the escrow is sized to the worst case up front and the unused remainder refunds.

Impact: You pay for the compute time you actually use, can never be over-charged past the cap, and get the rest back.

Bonded stake contributes to a host's selection ranking (w_stake), but only once its verified-success rate clears a reliability floor.

Impact: Stake amplifies already-reliable hosts and can never let an unreliable one buy its way to the top.

The duckton DuckDB extension is officially published — INSTALL duckton FROM community; LOAD duckton;

Impact: Anyone can install the client with one SQL line, no build required.

Once per epoch, a Merkle root summarizing many off-chain receipts is written on-chain, chained to the previous one.

Impact: Cheap tamper-proof history: rewriting any old record would change every later root.

A single on-chain contract holding the economic settings (fees, slashing %, stake tiers) every node reads.

Impact: One source of truth that can be updated in place — no node ships hard-coded economics.

A token minted 1:1 when you stake, as on-chain proof of your bond — but transfer-locked.

Impact: You can't sell it to dodge slashing; it's an accountability badge, not a tradeable asset.

A waiting period before staked funds can be withdrawn, during which they're still slashable.

Impact: Stops a worker from cheating and instantly cashing out before it gets caught.

A two-way signature linking a node's identity to a TON wallet (each signs the other).

Impact: Makes collusion visible (linked wallets) and ties payouts/penalties to a real account.

Testnet uses play-money for trying things; mainnet uses real funds.

Impact: Mainnet is guarded behind an explicit opt-in so you can't spend real money by accident.

Public jobs can run entirely off-chain for free; only paid jobs touch the blockchain.

Impact: You only pay (and wait on chain) when you actually want economic guarantees.