Playbook

BareNFTAuction: Claim, Rueckerstattung und Notfallrechte (Barenft Auktion Claim Rueckerstattung Notfallrechte)

Englische Auktion: Bid, Claim, Cancel, Reserve-Unterschreitung und Owner-Emergency transferNft/transferFunds Trade-offs.

Bare Crypto Solidity Marketplace-Protokoll

Teil 4 von 5

BareNFT, Reserve-Escrow, englische Auktion und NFT-gated BareToken-Emissionen in Remix IDE mit OpenZeppelin-v4.1-GitHub-Imports — ohne Hardhat/Foundry — inkl. ADRs, schwacher RNG und Notfall-Trade-offs.

Bare Crypto Solidity marketplace protocol diagram

Die Uhr endet; ETH und NFT (Non-Fungible Token) muessen gemeinsam aufloesen

BareNFTAuction ist eine owner-operated englische Auktion: NFT im Escrow, jeder Bid erstattet dem vorherigen maxBidder sofort, claimTokenFromAuctionByTokenId verteilt NFT und ETH nach Reserve-Regeln. cancelAuctionByTokenId erstattet und gibt das NFT an den Seller. Emergency transferNft/transferFunds liegen wieder beim Owner — Rettung und Rug teilen eine Tuer.

Owner escrow NFT → createNewAuction(endBlock, reserve, id, start)
        |
   bid() > maxBid ── refund previous maxBidder
        |
   endBlock reached
        |
   claim: maxBid < reserve? refund + NFT→seller
          else ETH→seller, NFT→maxBidder
        |
   cancel / emergency transfer*

Dieser Teil fixiert Auktions-Lebenszyklus, Claim/Refund-Pfade und den ADR-Trade-off der Notfallrechte.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Englische Auktion
Offene steigende Gebote; jedes neue Gebot schlaegt den Leader und loest Refund aus.

📦 Reserve Price
Liegt maxBid unter Reserve, kein Verkauf: NFT zurueck an Seller, Bid erstattet.

📦 Claim Settlement
Nach Ende ruft Seller oder maxBidder die NFT/ETH-Verteilung auf.

📦 Push Refund
Sofortige ETH-Rueckgabe an den vorherigen maxBidder bei hoeherem Bid.

Push-Refunds vereinfachen UX, koennen aber den Bid-Pfad bei failing receive blockieren; Pull-Payment ist ein alternativer ADR.

ADR: owner-created englische Auktion

Entscheidung: nur der Owner erstellt Auktionen; endBlock nach aktuellem Block; keine neue Auktion fuer tokenId bevor die vorherige endet. Begruendung: Bare Crypto plant Vitrinen-Auktionen nach Operator-Kalender. Kosten: keine permissionless Seller-Auktionen; setTokenContract und setOwner sind owner-gebunden — die Protokollflaeche haengt am Operator-Key.

Bid-, Claim-, Cancel-Fluss

bid prueft startingBid und maxBid, erstattet den vorherigen maxBidder via call{value}, aktualisiert dann maxBid/maxBidder. claimTokenFromAuctionByTokenId: kein maxBidder → NFT an Seller; maxBid unter Reserve → Refund + NFT an Seller; sonst ETH an Seller, NFT an Winner. cancel erstattet und gibt NFT zurueck solange offen. Diese drei Pfade versuchen die Escrow-Invariante: Geld und NFT loesen gemeinsam auf.

bid → refund old leader → set new leader
claim:
  no bid → NFT seller
  below reserve → refund + NFT seller
  else → pay seller + NFT winner
cancel → refund leader + NFT seller

Fehlerfall: stuck Refunds, Griefing, Emergency

Ist der vorherige Bidder ein Vertrag, der auf receive revertiert, stirbt der neue Bid an require(success) — Griefing-Vektor. Beim Claim kann ein fehlgeschlagenes seller.call riskieren, trotzdem NFT zu transferieren, wenn success auf dem Zweig nicht erzwungen wird. Emergency transferNft zieht das NFT ohne ETH-Settlement; maxBidder-Fonds koennen stecken bleiben. Performance: jeder Bid pusht auf Bid[]; lange Historien bloehen Storage und View-Gas.

Die am häufigsten verwechselten Zuordnungen

❌ Englische Auktion heisst: jeder darf oeffnen
✓ In dieser Implementierung ist createNewAuction owner-only

❌ Gebote unter Reserve verbrennen
✓ Im Claim-Pfad wird maxBidder erstattet und das NFT geht an den Seller

❌ Emergency-NFT-Pull raeumt auch Bids
✓ transferNft erstattet ETH nicht automatisch; Fonds koennen stecken bleiben

Checkliste zur Prüfung des eigenen Systems

  1. Wer darf claim aufrufen — nur maxBidder oder auch Seller?
  2. Was passiert mit einem neuen Bid, wenn der vorherige Bidder auf receive revertiert?
  3. Welchen Zustand zeigt die UI nach Claim unter Reserve?
  4. Worin unterscheiden sich cancel und emergency transferNft fuer Fonds?
  5. Wie gross kann Bid[] wachsen, gibt es ein View-Limit?

Was aus diesem Teil bleiben sollte

  1. BareNFTAuction ist eine owner-operated englische Auktion mit expliziten Claim/Refund-Pfaden.
  2. Push-Refund-UX bringt Griefing- und Stuck-Bid-Risiko mit.
  3. Emergency-NFT-Pulls settlen die ETH-Seite nicht automatisch.

Ein End-Block reicht nicht; Sie brauchen einen Claim-Pfad, der ETH und NFT gemeinsam schliesst.

FAQ

Häufige Fragen

Was ist Englische Auktion?

Offene steigende Gebote; jedes neue Gebot schlaegt den Leader und loest Refund aus.

Was ist Reserve Price?

Liegt maxBid unter Reserve, kein Verkauf: NFT zurueck an Seller, Bid erstattet.

Stimmt es, dass „Englische Auktion heisst: jeder darf oeffnen“?

In dieser Implementierung ist createNewAuction owner-only

Was legt dieser Teil fest?

Dieser Teil fixiert Auktions-Lebenszyklus, Claim/Refund-Pfade und den ADR-Trade-off der Notfallrechte. BareNFTAuction ist eine owner-operated englische Auktion: NFT im Escrow, jeder Bid erstattet dem vorherigen maxBidder sofort, claimTokenFromAuctionByTokenId verteilt NFT und ETH nach Reserve-Regeln. cancelAuctionByTokenId erstattet und gibt das NFT an den Seller. Emergency transferNft/transferFunds liegen wieder beim Owner — Rettung und Rug teilen eine Tuer.

Gelernte Engineering-Prinzipien

  • Auktions-ADR muss Create-Autoritaet, Reserve-Regel und Refund-Modell gemeinsam schreiben.
  • Bei Push-Refund Griefing und Pull-Payment-Alternative dokumentieren.
  • Emergency NFT/ETH-Exits ohne Bruch der Claim-Invariante entwerfen.

Weiterlesen

Weiterlesen

Nachster Teil der Serie

Nachster Teil der Serie

Aus derselben Serie

Paylaş