How do I set up a claim page builder for a community NFT drop with multi-wallet access and presale gating?

To set up a claim page builder for a community NFT drop with multi-wallet access and presale gating, you usually want three pieces:

1. A mint/claim contract
2. A gated frontend claim page
3. Wallet/account handling that supports multiple wallets per user

Here’s a practical blueprint.

---

1) Define the claim flow

Decide how users should claim:

• Public claim: anyone can claim once open
• Presale claim: only approved wallets can claim before public launch
• Allowlist/whitelist claim: gated by wallet address
• Token-gated claim: only holders of a specific NFT / token can claim
• Multi-wallet support: user can connect and switch between several wallets, and each eligible wallet can claim independently

For a community drop, a common setup is:

• Phase 1: Presale
  • Only allowlisted wallets or holders of a community token
  • Limited supply and/or reduced price
• Phase 2: Public mint
  • Open to everyone
• Per-wallet limits
  • e.g. 1 claim per wallet during presale, 2 total during public sale

---

2) Build the smart contract with gating support

Your contract should expose functions like:

• claim(quantity)
• presaleClaim(quantity, proof) or presaleMint(...)
• setSalePhase(phase)
• setMerkleRoot(root) for allowlist gating
• hasClaimed(address) or per-wallet mint tracking
• maxPerWallet
• maxSupply

Common gating methods

A. Merkle allowlist

Store a Merkle root of eligible addresses.

Frontend:

• User connects wallet
• App checks if wallet is in allowlist
• If yes, it fetches a Merkle proof
• It calls the presale mint function with proof

B. Signature-based gating

A backend signs a message authorizing a wallet to mint.

Useful if:

• eligibility changes dynamically
• you want private presales with server-side rules

C. Token ownership gating

Contract checks if wallet holds required NFT/token.

Useful if:

• community pass or previous NFT collection determines access

---

3) Multi-wallet access: what it really means

“Multi-wallet access” can mean one of two things:

Option 1: One user can connect multiple wallets

The UI lets users:

• connect Wallet A
• disconnect
• connect Wallet B
• claim from each eligible wallet

Option 2: One account can link multiple wallets

Users sign a message to link wallets to a profile. Then:

• they can see all linked wallets
• claim eligibility is tracked across them
• you can prevent abuse if desired

Recommended approach

For a drop page, the simplest and safest is:

• support wallet switching
• keep claim eligibility tied to each wallet address
• optionally let users link wallets in a backend if you need account-level analytics or special access

---

4) Set up the claim page builder

If you’re building a reusable “claim page builder,” make it configurable with these inputs:

Builder configuration

• Collection name
• Chain
• Contract address
• Sale phases
• Start/end time for presale/public sale
• Allowlist source
• Price per phase
• Max per wallet
• Max supply
• Theme/logo/brand assets
• Claim button text
• Success/error states
• Optional NFT metadata / reveal config

Frontend components

• Wallet connect button
• Network detection/switching
• Eligibility checker
• Claim button
• Quantity selector
• Countdown timer
• Phase badge: “Presale live” / “Public live”
• Status panel: connected wallet, claimed count, remaining supply

---

5) Backend services you may need

Even if minting is on-chain, a backend helps with:

• generating Merkle proofs
• signing claim permissions
• storing linked wallet relationships
• tracking claim events
• serving allowlist eligibility status
• managing phase schedules and page config

Minimal backend endpoints

• GET /claim-config
• GET /eligibility?address=0x...
• GET /proof?address=0x...
• POST /link-wallet
• POST /unlink-wallet

---

6) Frontend logic for presale gating

Typical flow:

1. User opens claim page
2. Connect wallet
3. Frontend checks chain/network
4. Frontend queries backend or contract for eligibility
5. If presale is active:
   • verify wallet is allowlisted or token-gated
   • fetch proof if needed
6. Show the correct mint button
7. User signs transaction
8. Page listens for confirmation and updates state

Example UI states

• Not connected
• Wrong network
• Presale not started
• Eligible for presale
• Not eligible for presale
• Public sale live
• Claimed already
• Sold out

---

7) Supporting multiple wallets in the UI

A good UX pattern is:

• “Connect wallet”
• Display current wallet address
• Add a “Switch wallet” button
• If the user wants multiple wallets:
  • support reconnecting a different wallet
  • optionally show a list of previously linked wallets

If using embedded wallets or account abstraction:

• users may also connect via email/social login
• you can map those to one profile while still letting them claim with different on-chain wallets if needed

---

8) Security considerations

Important safeguards:

• Never trust frontend-only gating
• Enforce presale eligibility in the smart contract
• Use per-wallet claim tracking
• Add reentrancy protection
• Protect admin functions with multisig
• Set proper network/chain checks
• Prevent double-claims by tracking claims on-chain
• Rate-limit proof endpoints on backend if using allowlists

---

9) Suggested tech stack

Frontend

• Next.js / React
• wagmi + viem or ethers
• WalletConnect / RainbowKit / Web3Modal

Backend

• Node.js / Next.js API routes
• Redis or DB for allowlists/linking
• Merkle tree generation library
• Optional signed message auth

Smart contract

• Solidity
• OpenZeppelin access control, merkle proof, pausability, reentrancy guard

Storage / metadata

• IPFS / Arweave / centralized CDN depending on project needs

---

10) Example architecture

Admin dashboard

• Upload allowlist CSV
• Set presale/public times
• Configure max per wallet
• Upload branding for page builder

Claim page

• Connect wallet
• Detect active phase
• Check eligibility
• Show claim action
• Support wallet switching

Contract

• Verifies proof or token ownership
• Mints only if valid
• Enforces limits

---

11) If you want to use a no-code / low-code builder

Some NFT infrastructure platforms let you configure:

• claim pages
• allowlists
• wallet gating
• dynamic mint phases
• custom branding

If you want custom multi-wallet behavior, make sure the platform supports:

• wallet switching
• custom auth/linking
• phase-based mint logic
• proof-based presale
• per-wallet mint caps

---

12) Recommended implementation pattern

If you’re building from scratch, do this:

On-chain

• ERC-721 or ERC-1155 contract
• Presale mint function with Merkle proof
• Public mint function
• Per-wallet mint limit
• Pause/unpause
• Admin phase controls

Off-chain

• Admin tool to upload allowlist
• Proof generation endpoint
• Wallet-linking system if needed
• Analytics dashboard

Frontend

• Claim page template builder
• Wallet connect + switch
• Eligibility display
• Presale/public state handling
• Claim transaction flow

---

13) Quick checklist

• Define presale/public phases
• Choose gating method: Merkle, signature, or token-based
• Implement on-chain per-wallet limits
• Add wallet connect + switch support
• Build backend for proofs/config
• Make page builder configurable
• Test on testnet
• Audit contract before mainnet launch

---

If you want, I can also provide:

1. a sample smart contract design for presale gating,
2. a Next.js claim page template, or
3. a database schema + API spec for the builder.