Reputation & Scarcity
Bound how many tasks a delegated graph can name and how many deposits any origin can place in your signal store.
On this page
A receiving kernel decides how much of a swarm’s work and influence it will carry. The signed task graph caps the work a delegation can fan out into, and capacity the receiver owns caps the observations it admits, so a sender gains nothing by minting more keys.
The two bounds answer different questions. The graph limits which tasks, capabilities, and routes a request may use. The signal store limits which signed deposits enter and how strongly each one counts. A deposit only ranks work, so the action an agent picks still needs its own capability, policy checks, and runtime admission.
Two kernels draw on one bucket the receiver owns
Take a receiver with 16 active peers, which allows four passport keys per kernel, three deposits per kernel and key, and twenty deposits in one shared bucket.
Each key carries at most three deposits
In the illustrative policy each kernel’s passport key may place three deposits in the window. A fourth from the same key is refused even though the shared bucket has room, so one key cannot crowd out the others. Reputation & Scarcity.
Each kernel can offer 4 × 3 = 12 deposits, so two admitted kernels reach 2 × 4 × 3 = 24 through their pair and passport limits. The shared bucket cuts the combined ceiling to 20. That is an upper bound for an initially empty, unchanged scope with otherwise valid deposits: the bucket does not reserve 10 slots for each kernel or guarantee fair arrival order.
New keys draw from the same shared bucket
Three limits intersect inside one receiver’s stored admission state. Their common scope is the reputation epoch, window id, treaty id, subject-class namespace, and subject class.
| Limit | Scope beyond the common one | Refusal |
|---|---|---|
token_capacity | None: shared across kernels and passport keys | rate_limit_exhausted |
max_deposits_per_pair | Origin kernel id and passport key hash | diversity_cap_exceeded |
ceil(sqrt(max(N, 1))) | Origin kernel id; counts distinct passport keys | sqrt_n_passport_cap_exceeded |
N is active_peers_in_treaty from the receiver’s context. The square-root rule caps how many distinct passport keys one origin kernel contributes through in a window, so changing a nonce or a signing key opens no fresh bucket. Whether two kernels belong to independent organizations is the operator’s admission and trust decision.
The SQLite runtime applies the deposit’s nonce, counter updates, passport record, and deposit in one admission transaction, and a failed admission rolls them all back. A capacity-one bucket accepts a first deposit, refuses the next, and still admits deposits under a different authorized window or treaty. Frames in one received batch keep separate outcomes.
Read more in Pheromone Store, which covers frame admission and the batch report.
Admitted volume is the smaller of the bucket and the origins’ product
For one unchanged scope, let M be the admitted origin kernels, S the passport cap, K the per-pair deposit cap, and T the shared token capacity. An initially empty store admits at most min(T, M × S × K).
N = 16 active peers
S = 4 ceil(sqrt(max(N, 1)))
K = 3 deposits per kernel/key pair
M = 2 admitted origin kernels
T = 20 shared token capacity
accepted <= min(T, M * S * K)
<= min(20, 24)
<= 20Change one input and a different limit binds:
- One admitted kernel: 12 deposits, because four keys of three deposits fill before the bucket does.
- Two admitted kernels: 20 combined, because the bucket fills before their pair capacity of 24.
- More keys from the same two kernels: still 20; a fifth key exceeds that kernel’s passport cap.
- Ten admitted kernels, same N and policy: still 20, with more competition for the same slots.
Fewer valid observations, existing usage, or another refusal lower the count. The model prices nothing: it gives no dollar cost for obtaining an admitted identity, manufacturing a credible observation, or compromising a verifier, and no safe share of adversarial influence.
A deposit’s influence is its decayed strength times two receiver weights
Concentration weights each admitted deposit by its decayed confidence, a caller-supplied peer weight, and a newcomer discount, so an admitted count says little about influence. The peer-weight callback returns a finite value between 0 and 1.
The newcomer factor is the smaller of 1 and age divided by the horizon, where age is the query epoch minus the passport’s first-seen epoch, with saturating subtraction, plus 1. At a horizon of 8, an age-one passport contributes one eighth of its otherwise weighted strength. Policy sets the horizon; 8 is the fallback.
The local eight-metric scorecard and marketplace feed tiers are separate reputation mechanisms. Signal concentration accepts a peer-weight callback; it does not automatically run either mechanism. Marketplace tier_3 requires a maximum supplied delta of at least 0.90, every supplied delta at least 0.80, and at least two distinct feed ids, an input property that leaves ownership and honesty to the operator.
Read more in Reputation, which documents the scorecard and the feed tiers.
Depth and fan-out cap how many tasks one graph can name
The verifier requires exactly one depth-zero root. Every other task names a parent with an edge to it, and every edge advances one depth level, so depth and fan-out bound the task count even when the graph adds fan-in edges.
D = maxDepth
F = maxFanout
tasks <= 1 + F + F^2 + ... + F^D
F > 1: (F^(D + 1) - 1) / (F - 1)
F = 1: D + 1
F = 0: rejected by the verifierdepth 0, fan-out 4 1 depth 3, fan-out 1 4 depth 3, fan-out 4 85 depth 4, fan-out 4 341 depth 3, fan-out 8 585
Outgoing edges per parent stay within maxFanout, which must be positive, and each node stays at or below maxDepth. Both bound one graph; a new graph can declare a different ceiling, and issuer admission decides whose graph is trusted. These are upper bounds on task records, with no throughput or deployment size implied. Extra edges spend fan-out capacity too.
Run the example project for depth 3 and fan-out 4
The example computes the same ceiling with checked integer arithmetic. Download the project and run it; you should see 85 task records.
cargo run --locked --bin scarcity -- 3 4depth 3, fanout 4: at most 85 task records This is a structural upper bound; it does not reserve workers or admit a bundle.
Budget, revocation, continuation, and route checks travel with the graph
A signed task graph makes a workflow’s intended shape portable between operators. Verification checks the shape and its evidence; runtime admission adds the stored reference, route, and continuation checks a request needs.
- Budget conservation. Each allocation’s five state totals equal
maxUnits, and allocation ceilings sum to at mosttotalUnitsunder checked addition. The pool is an unsigned accounting record of declared units; payment and settlement are separate. - Revocation view. The signed epoch’s references, list digest, validity, and revoked membership are checked, and continuations bind its identifier and root. The verifier checks the epoch it is given; its opaque id says nothing about whether a newer view exists.
- Single-use continuation. The verifier checks the token and runtime admission consumes its id through the store. A refused, failed, or panicking consume callback denies the request. Reuse across requests is stopped by the store, since the pure bundle verifier keeps no consumption state.
- Selected route. Runtime admission compares live route metadata with the referenced route-plan receipt and verifies the authority bundle. The signed plan and the dispatch controls must agree, since a route receipt is evidence and the network boundary is the dispatcher’s.
Read more in Task Graphs, Sub-Agent Budgets, and Revocation Epochs.
Independence, accuracy, and origin ownership stay operator decisions
The operator supplies what each bound reads: trusted issuers, authorized evidence, live request context, and the admission store for work; admitted passports, a live scarcity policy, workflow evidence, and receiver-owned counters for deposits; a peer-weight function, reputation epoch, and newcomer context for weighting. Capacity then bounds accepted volume, and three decisions stay with the operator:
- Collusion and competition. Several admitted kernels can coordinate observations or compete for one shared bucket. The square-root rule limits keys per kernel and the bucket limits total volume; review origin admission, concentration inputs, and what acting on the signal triggers.
- Credible-looking observations. In required mode, observation-cost verification checks deposit-bound evidence against the receiver’s policy and trusted verifier roots, which makes the evidence inspectable. Choose the required evidence and roots per subject class, and keep action authorization independent of the signal.
- Re-issuance and origin ownership. The receiver resolves admitted passports by kernel id and key hash, with revocation and validity checks, so a new key is still the same origin. Who controls several admitted kernels is context beyond those keys; keep origin admission, first-seen history, and revocation consistent with that decision.
A graph signature shows control of a key and binds the signed material; whether the issuer should have authorized the workflow is a trust decision. A compromised trusted signer can issue a different graph, and a delegate can misbehave inside the scope it was granted. Verification, storage, policy evaluation, and tool execution all consume resources, so request limits and deployment boundaries stay part of operating the system. The Assurance Model defines the wider boundary.
Source for these checks
- Swarm authority verifier: graph shape, declared budget accounting, and the supplied revocation view.
- Runtime swarm reference verification: stored evidence, route comparison, and continuation selection.
- SQLite deposit admission: transactional counters and their exact scope.
- Runtime receiver tests: the capacity-one bucket cases.
- Concentration calculation and marketplace tier mapping.