A verified listing's balance check counts the wallet's other open verified listings and its unpaid awards

migrations/0086_listings_verified_funder_index.sql

@@ -0,0 +1,6 @@
+-- A verified listing's balance read must cover it together with the same
+-- wallet's other open verified listings in that asset (createListing in
+-- src/society.ts). That check looks the wallet's verified listings up by
+-- address at posting time; without this index it scans every listing ever
+-- posted. Partial: promise and funded listings never take part in the sum.
+CREATE INDEX IF NOT EXISTS idx_listings_verified_funder ON listings(funder_address, token, chain_id, id) WHERE funding_mode = 'verified';

schema.sql

@@ -891,6 +891,8 @@ CREATE INDEX IF NOT EXISTS idx_listings_expiry ON listings(expiry, id);
 -- Migration 0062: moderated-rows-only index (after idx_listings_expiry, which tests use as a slice END anchor).
 CREATE INDEX IF NOT EXISTS idx_listings_moderated ON listings(id, mod_state) WHERE mod_state IS NOT NULL;
 CREATE INDEX IF NOT EXISTS idx_listings_grant ON listings(grant_id, id);
+-- Migration 0086: the verified-cover sum looks a wallet's open verified listings up by address.
+CREATE INDEX IF NOT EXISTS idx_listings_verified_funder ON listings(funder_address, token, chain_id, id) WHERE funding_mode = 'verified';
 
 -- Submissions: work handed in against an open listing. No claiming and no
 -- assignment: while a listing is open anyone may submit, and the funder picks

src/listings.ts

@@ -41,8 +41,10 @@ export interface ListingInput {
   // Proof of funds, optional but recommended: the wallet that will pay, and its
   // EIP-191 signature over listingPreimage(). When present, the registry reads
   // that wallet's USDC balance from two agreeing providers at posting time and
-  // refuses a listing the wallet cannot cover; and every receipt on the listing
-  // must come from this address.
+  // refuses a listing the wallet cannot cover (for a verified listing, cover
+  // for it plus the wallet's other open verified listings in that asset and the
+  // unpaid awards on its closed ones, at posting); and
+  // every receipt on the listing must come from this address.
   funder_address?: unknown;
   funder_signature?: unknown;
   // Same door check as a post: the title and condition are citizen text and

src/settlement.ts

@@ -37,7 +37,7 @@ export const SETTLEMENT_MODES = ["automatic", "requester", "verifier"] as const;
 export type SettlementMode = (typeof SETTLEMENT_MODES)[number];
 
 export const FUNDING_MODE_NOTE =
-  "promise: the funder has committed nothing; their settlement history is the only thing standing behind it. verified: this registry read the named wallet's balance at a point in time and it covered the listing's maximum liability at that instant; the funds are NOT reserved, NOT locked and NOT escrowed, and the wallet may move them the next second. funded: the listing's maximum liability is committed up front. On a settlement_version 3 listing that means an on-chain escrow named in this listing's own hashed terms, and `funding_status` on the listing response carries what the chain actually says: this registry reads it rather than repeating the claim. On the older adapter path it means a settlement adapter, and committed_atomic says how much and which adapter holds it.";
+  "promise: the funder has committed nothing; their settlement history is the only thing standing behind it. verified: this registry read the named wallet's balance at a point in time and it covered the listing's maximum liability at that instant, together with the maximum liability of every other open verified listing that named the same wallet in the same asset, and the unpaid awards still owed on that wallet's withdrawn or expired verified listings, when this one was posted, so at posting one balance is never counted as cover twice; the funds are NOT reserved, NOT locked and NOT escrowed, and the wallet may move them the next second. funded: the listing's maximum liability is committed up front. On a settlement_version 3 listing that means an on-chain escrow named in this listing's own hashed terms, and `funding_status` on the listing response carries what the chain actually says: this registry reads it rather than repeating the claim. On the older adapter path it means a settlement adapter, and committed_atomic says how much and which adapter holds it.";
 
 export const SETTLEMENT_MODE_NOTE =
   "Who decides that a submission is entitled to the amount. automatic: this registry evaluates a narrow declared check against state it can read itself, and no one judges the work; on a funded listing the money is released in the same request, which is the FUND -> SUBMIT -> PAID path. requester: the funder accepts, under the silence policy declared at posting time. verifier: a citizen holding a verifier binding filed on this listing before the verdict signs a pass or fail. IN ALL THREE, THE DECISION ITSELF MAKES THE AWARD PAYABLE: a verifier's pass is not a recommendation the funder then confirms, because a listing that declared a verifier and still required the funder to agree would have handed the funder a veto it never declared. The one award that is not born payable is a seat RESERVED before the work, which only a requester-settled listing can do and only when it declared award_ttl_seconds beforehand. The registry is not a judge in any mode: in automatic it runs a check the funder wrote down before the work, and in the other two it records a named party's decision.";