Listing-Entdeckung per totalSupply-Scan (Listing Entdeckung Per Totalsupply Scan)

Ohne Indexer ist jeder Refresh ein Chain-Scan

Der Bare-Crypto-Marketplace findet offene Listings nicht über Event-Index oder Subgraph, sondern mit totalSupply() plus tokenId-Schleife. Jeder Schritt addiert Calls wie wasNftSold, isListingOpenByTokenId und getLastListingByTokenId. Mit wachsendem Supply wächst die Kosten — schlimmer mit Polling — und Reserve wiederholt den Scan etwa alle 30 Sekunden.

getListings(sold=false)
  maxToken ← NFT.totalSupply()
  for tokenId = maxToken … 1:
    wasSold?  open?  isListing?
    → maybe getListingInfo(tokenId)
         ↓
  N tokens × M RPC calls / poll
  poll every ~30s (Reserve / Profile)
         ↓
  Infura rate-limit → empty / stale grid

Dieser Teil schneidet den Discovery-Algorithmus hinter dem OpenSea-ähnlichen Grid auf — und warum er ADR-Stoff ist.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 totalSupply-Scan
Listing-Menge durch Rückwärtslaufen der tokenIds ab Supply entdecken.

📦 N×RPC
Mehrere eth_calls pro Token; multipliziert mit Poll-Frequenz gegen Quota.

📦 Stale Listing
Verkauftes/storniertes Listing wirkt noch offen — Poll-Lag oder Teilfehler.

📦 Infura Rate Limit
Request-Budget pro Projekt; Überschreitung lässt Calls scheitern oder stocken.

Eine Schleife für kleine Rinkeby-Collections ist kein Mainnet-Produktfeature.

Algorithmische Wahrheit

getListings liest totalSupply via getTokenSupply() und läuft von maxToken nach 1. Pro Token: sold/open/listing und optional getListingInfo. Leere Bereiche verbrennen trotzdem RPC.

Cost model (approx)
  cost ≈ totalSupply × calls_per_token × polls_per_minute
  UI cards may add metadata/IPFS reads on top

30-Sekunden-Polls und stale UI

Reserve startet getListings beim Mount und wiederholt mit setInterval(..., 30000). Profile scannt Besitz ähnlich; Viewer/Karten 10–15s. Kauf möglich, Grid eine Poll-Länge stale — oder leer unter Rate-Limit.

Infura-Fehlermodus

Der Scan trifft den Read-Node (Rinkeby Infura HTTP/WSS). Bei Quota können try/catch-Pfade wasSold=false oder leere Strings liefern; das Grid wird still falsch. Keys im Repo vergrößern den Blast Radius — Docs drucken keine Projekt-IDs; Env + Edge-Limits gehören ins ADR.

ADR: Listing discovery
  Accepted (prototype): scan totalSupply client-side
  Rejected (then): subgraph / event indexer
  Consequence: rate limits, stale polls, O(supply) cost
  Follow-up: index Transfer/Listing events; paginate

Unterschied zu OpenSea

OpenSea lässt nicht jeden Browser den vollen Supply laufen; es gibt Index + API. Bare Crypto kopiert die IA-Referenz, nicht die Discovery-Infrastruktur.

Die am häufigsten verwechselten Zuordnungen

❌ totalSupply-Scan = Production-Discovery
✓ Prototyp-Symptom fehlender Indexer

❌ 30s-Poll ist Echtzeitmarkt
✓ Poll ist Stale- und Quota-Risiko

❌ RPC-Fehler in try/catch schlucken = sichere UI
✓ Stille falsche Listings sind schlimmer

❌ Infura-Keys im Client-Bundle sind ok
✓ Leak + gemeinsame Quota; Env/Proxy bevorzugen

Checkliste zur Prüfung des eigenen Systems

1. Wie viele eth_calls pro Token in einem getListings-Lauf?
2. Was kostet ein Poll bei 10× Supply?
3. Welcher leere/falsche UI-Zustand unter Rate-Limit?
4. Wie lange kann das Grid nach Kauf stale bleiben?
5. Welche Events würden den Scan ersetzen?

Was aus diesem Teil bleiben sollte

1. Listing-Discovery ist ein totalSupply-Scan — kein OpenSea-Index.
2. N×RPC × 30s-Poll macht Infura-Quota und stale UI unvermeidlich.
3. ADR: Prototyp akzeptieren, Indexer folgen — skaliert nicht still.

Jedes tokenId abfragen ist kein Marktplatz; es ist ein Lasttest.