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.
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
- Wer darf claim aufrufen — nur maxBidder oder auch Seller?
- Was passiert mit einem neuen Bid, wenn der vorherige Bidder auf receive revertiert?
- Welchen Zustand zeigt die UI nach Claim unter Reserve?
- Worin unterscheiden sich cancel und emergency transferNft fuer Fonds?
- Wie gross kann Bid[] wachsen, gibt es ein View-Limit?
Was aus diesem Teil bleiben sollte
- BareNFTAuction ist eine owner-operated englische Auktion mit expliziten Claim/Refund-Pfaden.
- Push-Refund-UX bringt Griefing- und Stuck-Bid-Risiko mit.
- 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
BareToken: NFT (Non-Fungible Token)-gated Emissionen und Missbrauch
Hashmasks-artige NFT-gated Claims: ~10e18/Tag, INITIAL_ALLOTMENT, 10-Jahres-emissionEnd — plus offene Mint-Flaeche und Missbrauchsszenarien.
Nachster Teil der Serie
BareNFTReserve: Escrow, RandomBuy und schwache RNG
Owner-only createNewListing, buy und randomBuy mit keccak256(revealNonce, block.difficulty, msg.sender) % 3 — schwache RNG, Owner-Marketplace-ADR…
Aus derselben Serie
BareNFT: Rollen, Pausable und Token-URI
BareNFT kombiniert ERC721 Enumerable/Burnable/Pausable mit AccessControl und role-gated mint(to, id, uri). Trade-offs von Per-Token-URI und Pause.