Mainnet Web3Modal und Wallet-Härtung (Mainnet Web3modal Wallet Haertung)

Mainnet bricht die Single-Wallet-Annahme

Gorillas Mainnet 1.8 verlässt den All-Stars/1.4-Pfad window.ethereum.enable(). Web3Modal öffnet mit cacheProvider; WalletConnect (Infura-Id) und custom Coinbase WalletLink (chainId: 1) kommen in providerOptions. ConnectWeb3 → ethers Web3Provider → address; Contract-Instanzen sprechen über den Modal-Provider.

Before (All-Stars / early)
  window.ethereum only → Web3

After (mainnet 1.8)
  Web3Modal
    ├─ WalletConnect (Infura)
    ├─ WalletLink / Coinbase (chainId 1)
    └─ injected (MetaMask)
         ↓
  provider → ethers Web3Provider
         ↓
  getNftContract(Web3(provider))

Dieser Teil schließt die Serie mit einer Mainnet-Readiness-Checkliste: Wallet-Vielfalt, Netz-Asserts, Gas und Adress-/ABI-Disziplin.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Web3Modal
Multi-Wallet-Connect-UI; WalletConnect/WalletLink über providerOptions.

📦 WalletConnect
QR-/Mobile-Wallet-Brücke; braucht Infura- (oder RPC-) Id.

📦 WalletLink
Coinbase-Wallet-Connector; appName, networkUrl, chainId.

📦 cacheProvider
Merkt den letzten Provider; Reconnect-UX mit Stale-Session-Risiko.

RPC-/Infura-Project-Ids sind Konfiguration — keine Secrets im Playbook. Keys leben in Env, nicht im Repo.

Warum MetaMask-only nicht reicht

Landing-FAQ sagt vielleicht noch MetaMask; Mainnet-Nutzer wollen Coinbase Wallet und mobiles WalletConnect. Ein injizierter Pfad killt Conversion. 1.8-Entscheidung: Multi-Connector-Modal, network: 'mainnet'.

User segments
  Desktop MetaMask
  Mobile WC
  Coinbase WalletLink
       ↓
  one ConnectWeb3() API

Connection-Lebenszyklus

ConnectWeb3: web3Modal.connect() → Web3Provider → getAddress. DisconnectWeb3: clearCachedProvider + provider.disconnect + reload. getNetwork liest netId vom Provider. Contract-Getter bauen Web3.eth.Contract aus initialState.provider — der alte appWeb3()-Infura-Fallback darf kein Mainnet-Signierpfad sein.

connect → address
getNetwork → chainId check
mint/reveal only if chainId OK
disconnect → clear cache → reload

ADR: Web3Modal als Wallet-Facade

Entscheidung: Mint/Reveal-Utils binden nicht direkt an window.ethereum; die Modal-Facade liefert Address und Provider. Plus: Connector hinzufügen ist Produktentscheidung. Minus: dualer ethers+web3-Stack und cacheProvider-Stale. Mitigation: chainId vor Mint asserten; Cache bei Disconnect löschen.

ADR-04 Web3Modal facade
  UI → ConnectWeb3 / DisconnectWeb3
  Utils → provider from modal state
  Guard → chainId === 1 before send
  Reject → wrong net / no provider

Mainnet-Failure-Playbook

1. Stub-Contract-Adressen in Production — Tx wirkt ok, State falsch. 2) Falsches Netz — Signatur auf Rinkeby/Goerli, Mainnet-Supply unverändert. 3) gasPrice: 0 — underpriced im Mempool. 4) ABI-Mismatch — multipleMint/reveal Encode fail. 5) Pinata/Infura-Keys im Client-Bundle — Secret-Leak (nie committen).

Hardening checklist
  ✓ real mainnet addresses
  ✓ chainId === 1 gate
  ✓ dynamic gas / tip
  ✓ ABI ↔ deployment lock
  ✓ secrets in env only

Die am häufigsten verwechselten Zuordnungen

❌ window.ethereum reicht; Modal ist Luxus
✓ Multi-Connector ist Mainnet-Conversion-Anforderung

❌ cacheProvider = immer verbunden bleiben
✓ Stale Provider mit disconnect + clearCachedProvider löschen

❌ Infura/Pinata-Keys in Constants
✓ Keys in Env/Secret-Store; minimale Client-Scope

Checkliste zur Prüfung des eigenen Systems

1. Wird nach Connect chainId === 1 assertet?
2. Ist provider vor Mint-Send non-null?
3. Hat gasPrice: 0 den Production-Build überlebt?
4. Sind nft/reserve/auction-Adressen verschieden und Mainnet?
5. Wurden WalletConnect / WalletLink auf echten Geräten getestet?

Was aus diesem Teil bleiben sollte

1. Der 1.8-Sprung: MetaMask-only → Web3Modal Multi-Wallet-Facade.
2. Mainnet-Härtung ist Adress-, Netz-, Gas-, ABI- und Secret-Disziplin.
3. Disconnect und Cache-Clear gehören zur Reconnect-UX.

Eine Wallet zu verbinden ist kein Feature; auf dem falschen Netz zu signieren ist ein stiller Production-Incident.