Sworn Indexer, a Ponder indexer for the Sworn registry on Ethereum mainnet, the settled WhitelistCurator game it reads, the IDMD seat transfers behind the Swarmed fact, and the IMD payments its community rules count: its own repository that runs on our Docker host and that the Sworn site reads instead of scanning logs in the browser. Decide, do not ask: a question blocks the job.

WHAT IT INDEXES (Ethereum mainnet, chainId 1):

1. The Sworn registry 0x0da2679000ea5380d1361cc3cca7d4e8c881f766 from block 26242885 (its deployment block), every event of its ABI: CardMinted(address indexed claimant, uint256 indexed tokenId); TraitRequested(address indexed claimant, uint16 indexed traitId, bytes32 requestId, bytes32 questionHash); Verified(address indexed claimant, uint16 indexed traitId, bytes32 requestId, bytes32 oracleRequestId); Missed(bytes32 requestId, uint16 traitId, uint8 reason); NoVerdict(bytes32 requestId, uint16 traitId, uint8 status, bytes32 reason, uint16 agreed, uint16 answered); Abandoned(bytes32 requestId); SpecRegistered(uint16 indexed traitId, address indexed registrant); SharedFactStored(uint16 indexed factId, bytes32 requestId, uint16 length); the ERC-721 Transfer(address indexed from, address indexed to, uint256 indexed tokenId); MetadataUpdate(uint256 tokenId) and BatchMetadataUpdate(uint256 fromTokenId, uint256 toTokenId). The verified ABI is served at https://sworn.sites.imd.fun/abi/Registry.json and lives in https://github.com/identity-md-launches/launch-2404-renderer-composer-registry.

2. The IMD token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, ERC-20 Transfer(address indexed from, address indexed to, uint256 value) with to equal to 0x4e0fa57bde726079356537e2f34d671e9f41adbc (the swarm's payee), from block 26038414. This is what community rule 10001 counts: a wallet meets it when it sent at least 5 such transfers between blocks 26038414 and 26279931 inclusive. Store every such transfer with block number, log index, transaction hash, from, value and block timestamp; a count per window is a query over these rows, never a stored total, because later rules may use other windows.

3. For every SpecRegistered, the rule itself, read from the registry with specOf(uint16) returns (uint8 kind, address target, string item, string arg, string fixedArg, uint256 fixedVal, string sumArg, uint8 op, uint256 threshold, uint64 fromBlock, uint64 toBlock, string name), stored with its registrant, block and transaction.

4. The settled WhitelistCurator game 0xcb0b0531e86a9ac36fa865ca8e3dbccf047fda91 from block 25769870 (deployment) to block 25789721 (the Settled event; nothing changes after it): Deposited(address indexed contributor, uint256 indexed hour, uint256 amount, uint256 creditedDelta, uint256 weightAdded, uint256 newWeight, uint256 txCount, uint256 hourTotal, uint256 earlyBps); FirstDeposit(address indexed contributor, uint256 indexed index, uint256 timestamp); HourSaved(address indexed savior, uint256 indexed hour, uint256 hourTotal); Settled. The verified ABI is served at https://sworn.sites.imd.fun/abi/WhitelistCurator.json. Known census: 19,522 contributors (FirstDeposit indices 1 to 19,522), 28,353 deposits, 41 HourSaved by 33 distinct saviors, hours 24 to 65 hold 5,958 deposits by 3,936 contributors; the first block of hour 24 is 25777045, FirstDeposit index 1000 is in block 25770897.

5. The IdentityMD seat collection IDMD 0x0000eC93127BAA929E58E97dd0095A2BFb38ec1D, ERC-721 Transfer(address indexed from, address indexed to, uint256 indexed tokenId), from block 25090085 (the start of the Swarmed window), kept per token as holding intervals per wallet (from block, to block or open). The Swarmed fact also needs accepted swarm work from the IMD control plane, which is offchain and out of scope here: the indexer answers only who held which seat when.

WHAT THE API ANSWERS (JSON over HTTP, no auth, CORS allowing https://sworn.vibingco.de and https://sworn.sites.imd.fun or any origin):

• GET /health: the chain head seen, the last indexed block per contract, whether the backfill is complete.
• GET /rules: every registered community rule with all its fields, registrant, block and transaction.
• GET /rules/:id/eligibility?wallet=0x...: for a kind-1 rule whose target is the IMD token and whose item is that Transfer event with the fixed to filter: the number of matching transfers from the wallet inside the rule's window, the threshold, met true or false, the blocks and transaction hashes counted, and the last indexed block. For any other rule shape: supported false, with the rule's fields.
• GET /wallets/:address: the card tokenId if minted, every request (traitId, requestId, state pending, verified, missed, noverdict or abandoned, with the reason or status codes), the verified traits, and the IMD payments to the payee with their blocks.
• GET /cards: every card with claimant, tokenId, current holder and mint block.
• GET /payments?wallet=0x...&from=BLOCK&to=BLOCK: the raw payee transfers of a wallet in a block range.
• GET /curator/stats: contributors, deposits, HourSaved count and distinct saviors, per-hour deposit counts and totals for hours 0 to 65, the settled block.
• GET /curator/wallets/:address: that wallet's deposits (block, hour, amount, weightAdded, newWeight, txCount), its first-deposit index and hour, its summed weightAdded and its rank by it, the hours it saved.
• GET /curator/top?n=32: the n wallets with the highest summed weightAdded, ordered, with the sums (the Top Weights candidates).
• GET /seats/:address: the IDMD tokens the wallet holds or held, each as intervals with from and to block and timestamps. Ponder's GraphQL endpoint may stay enabled beside these routes.

WHERE IT RUNS, two targets from one repository and one image, differing only in environment variables: (a) Railway, the swarm's deploy target, as the skill provides (Dockerfile-based service, PORT from the environment, data in Railway Postgres through DATABASE_URL or on a Railway volume, a railway.json or equivalent); (b) our own Linux Docker host (x86_64, Docker Compose, 2 vCPUs shared with other containers, about 512 MB of RAM to spare) behind a Caddy reverse proxy on a shared Docker network: one container plus one named volume, data in PGlite on that volume when DATABASE_URL is absent, no separate database container on this host, memory kept under 512 MB during backfill and tailing. Environment: PONDER_RPC_URL_1 (required), DATABASE_URL (optional Postgres), PORT, CORS_ORIGINS (comma-separated, default the two Sworn hosts). The backfill must complete on a public RPC that caps eth_getLogs block spans and rate-limits (publicnode, mevblocker or tenderly) without manual help; the process keeps tailing new blocks with automatic reconnects, and a restart resumes from the stored progress, never from zero.

DELIVERABLE: the repository with ponder.config.ts, ponder.schema.ts, the indexing functions, the API routes, a Dockerfile, a docker-compose.yml with the volume, the Railway configuration, .env.example, and a README with one section per target that says how to run it locally, how to deploy it on Railway and how to deploy it on a Docker host, how long the backfill took, which getLogs block span and RPC limits it tolerates, and every endpoint with an example response taken from a real run against mainnet. No secret in the repository.