BareNFTReserve: Escrow, RandomBuy und schwache RNG (Barenft Reserve Escrow Und Randombuy Entropie)

Escrow-Trust, Lotterie-Misstrauen

BareNFTReserve legt das NFT in den Vertrag und oeffnet Preise nur ueber owner-only createNewListing; buy settlet ein festes Listing. randomBuy baut aus keccak256(revealNonce, block.difficulty, msg.sender) % 3 ein 'zufaelliges' Index-Tripel — bewusst schwache On-Chain-Entropie. Das ist das Herz des Bare-Crypto-ADRs fuer einen owner-operated Marketplace: Trust liegt beim Operator; Chance ist UX-Zucker.

Owner ──transfer NFT──> BareNFTReserve (escrow)
  createNewListing(tokenId, price)
        |
        +── buy(tokenId) ──ETH──> seller, NFT──> buyer
        |
        +── randomBuy() ── keccak(nonce, difficulty, sender) % 3
        |
        +── emergency: transferNft / transferFunds

Dieser Teil fixiert Reserve-Escrow, schwache RNG und den Trade-off der Notfallrechte.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Escrow-Listing
NFT wird zuerst an den Vertrag transferiert; Listing oeffnet nur wenn ownerOf der Vertrag ist.

📦 Owner-operated Marketplace
Listing-Erstellung und Notfall-Exits an einen Owner gebunden — nicht permissionless.

📦 Schwache On-Chain-RNG
Pseudo-Zufall aus Difficulty + Nonce + Sender, beeinflussbar durch Miner/Caller.

📦 Emergency Exit
Owner-Bypass des Escrows via transferNft / transferFunds.

Owner-operated Escrow ist ein anderer Produkt-ADR als ein OpenSea-aehnlicher permissionless Markt; randomBuy addiert Chance, aendert Trust nicht.

ADR: owner-operated Reserve

Entscheidung: nur der Owner darf createNewListing; das NFT muss bereits im Vertrag liegen. Begruendung: Bare Crypto steuert Vitrinen-Bestand als Single Operator und vermeidet Fake-Listings eines permissionless Seller-Modells. Kosten: zentraler Operator — Open/Close, Preis, closeListing sind owner-gated. Das ist ein ADR 'Operator-Storefront-Escrow', kein Protokoll-Marketplace.

buy, randomBuy und Entropie-Diagramm

buy laedt den letzten tokenIdToListing-Eintrag, verlangt msg.value >= price, dann seller.transfer und safeTransferFrom. randomBuy kommentiert den Preis-Require aus; randomId liefert drei Indizes via % 3 und versucht bis zum ersten Verkauf. Die Entropie ist vorhersagbar oder miner-beeinflusst — kein fairer Zufall, sondern Vitrinen-Mystery-Box-UX.

revealNonce ++
keccak256(nonce, block.difficulty, msg.sender)
        |
            v
   index = hash % 3
   [i, i+1, i+2] mod 3
        |
        v
 try listings until sold

Fehlerfall: schwache RNG, Reentrancy, Emergency

Sofortiges seller.transfer(msg.value) in buy/randomBuy ist eine schwache Checks-Effects-Interactions-Flaeche; ein boeswilliger Seller-Vertrag kann Reentrancy versuchen. RNG-Schwaeche: im selben Block kann der Caller simulieren, in welchen %3-Bucket er faellt. Emergency transferNft/transferFunds dienen der Incident-Rettung, leeren aber bei Owner-Key-Compromise das gesamte Escrow. Performance: waechst tokenIdToListing, steigen Gas und Historien-Komplexitaet von getLastListingByTokenId.

Die am häufigsten verwechselten Zuordnungen

❌ block.difficulty-Random macht faire NFT-Verteilung
✓ Das ist schwache RNG; Mystery-UX ja, faire Mint/Raffle nein

❌ NFT im Escrow bedeutet permissionless Markt
✓ Ist Listing-Erstellung owner-only, ist das Produkt eine Operator-Vitrine

❌ Emergency Transfer verbessert nur Sicherheit
✓ Dieselbe Tuer ist bei Compromise ein Rug-Vektor; ohne Timelock/Multisig Single-Point-Risk

Checkliste zur Prüfung des eigenen Systems

1. Wer darf createNewListing — nur Owner oder jeder Seller?
2. Ist die randomBuy-Preispruefung aktiv oder auskommentiert?
3. Welche Wallet haelt transferNft/transferFunds, gibt es Multisig?
4. Kann ein Caller randomBuy im selben Block vorhersagen?
5. Welchen tokenIdToListing-Eintrag behandelt die UI als aktuell?

Was aus diesem Teil bleiben sollte

1. BareNFTReserve ist ein Owner-Escrow-Storefront-ADR, kein permissionless Marketplace.
2. randomBuy-Entropie ist bewusst schwach — UX-Zucker, keine faire Chance.
3. Notfallrechte oeffnen Rettung und Rug mit demselben Schluessel.

Liegt Escrow-Trust beim Operator, ist Wuerfeln Dekoration, kein Protokoll.