Burn a Token,
Mint an NFT

The Setup, and Which Standard Fits

The goal in one line: a user holds a fungible token, they burn it, and in exchange a distinct, non-fungible token lands in their wallet. Before writing a single line, the first real decision is how many contracts and which standards.

Two credible shapes:

The deciding question

It almost always reduces to one thing: do the resulting NFTs need to be first-class ERC-721s? Traded on OpenSea-style markets, referenced by other contracts that expect the ERC-721 interface, enumerable? If yes → Option A. If they're really receipts or badges that live inside your own ecosystem → Option B's atomicity and single-approval UX is very attractive.

Atomic Redemption: Contracts Calling Contracts

The core worry people have — "can redeeming the ERC-20 automatically trigger the NFT mint?" — has a clean answer: yes, in the same transaction. On the EVM, one contract can call a function on another contract synchronously. So "burn the ERC-20 and mint the ERC-721" happens atomically: if the mint reverts, the burn reverts too, and vice versa. No async, no second transaction, no keeper or off-chain bot needed. One redeem() call does both.

The minimal three-contract sketch

Solidity ^0.8, leaning entirely on OpenZeppelin:

// RedeemableToken.sol — the fungible token
contract RedeemableToken is ERC20, ERC20Burnable, Ownable {
  constructor() ERC20("Redeemable", "RDM") Ownable(msg.sender) {}
  function mint(address to, uint256 amt) external onlyOwner { _mint(to, amt); }
}

// ResultNFT.sol — the NFT you get back
contract ResultNFT is ERC721, Ownable {
  uint256 public nextId;
  address public redeemer;
  function setRedeemer(address r) external onlyOwner { redeemer = r; }
  function mintTo(address to) external returns (uint256 id) {
    require(msg.sender == redeemer, "not redeemer");
    id = nextId++;
    _safeMint(to, id);
  }
}

// Redeemer.sol — the orchestrator
contract Redeemer {
  ERC20Burnable public immutable token;
  IResultNFT   public immutable nft;
  uint256 public immutable cost;   // ERC-20 burned per redemption

  // user must approve(this, cost) first
  function redeem() external returns (uint256) {
    token.burnFrom(msg.sender, cost);   // burn BEFORE mint
    return nft.mintTo(msg.sender);
  }
}

Deploy Order & the Permission Model

Each contract needs to know about the other — a chicken-and-egg problem. It's solved by deploying one first, then using owner-guarded setter functions to connect them. Standard pattern. The precise sequence:

• Deploy the ERC-721 first. It has to exist before anything can hold a reference to it.
• Deploy the ERC-20 / redeemer, passing it the ERC-721's address so it knows what to call.
• Grant mint permission. The NFT stores an authorized minter and checks msg.sender against it, so you call setRedeemer(redeemerAddress) after deploy. Without this, anyone could mint for free.
• Wire the reverse direction if it wasn't set in a constructor — e.g. setNftContract(...).

Two permissions must exist

Where should the redeem logic live?

You can put redeem() directly in the ERC-20, or use a separate third "redeemer" contract. The third-contract approach is worth the extra deployment because:

• Each token contract stays a clean, standard implementation wallets and marketplaces recognize.
• The redemption rules (cost, which NFT, caps) are the part most likely to change or carry bugs — isolating them means redeploying just the redeemer.
• Permissions stay legible: the ERC-20 grants burn allowance, the ERC-721 grants mint rights, and only the redeemer holds both.

For a simple 1:1 flow, putting it in the ERC-20 directly is valid and saves a deployment. Nothing wrong with it.

The Factory Pattern

If you'll be spinning up many ERC-20 + ERC-721 pairs, doing the deploy-deploy-setMinter dance by hand every time is error-prone. A factory contract automates the overhead: one createSet() call deploys everything and wires the permissions in a single atomic transaction.

• No manual sequencing.
• No separate setMinter call you might forget.
• No chance of a half-wired set sitting around in a broken state — if any step reverts, the whole thing rolls back.

contract SetFactory {
  function createSet(uint256 cost) external returns (address t, address n, address r) {
    ResultNFT nft   = new ResultNFT();            // deploy NFT
    RedeemableToken tok = new RedeemableToken();     // deploy token
    Redeemer red    = new Redeemer(tok, nft, cost);  // deploy redeemer
    nft.setRedeemer(address(red));                    // wire mint rights
    // all-or-nothing: one tx, no broken half-states
    return (address(tok), address(nft), address(red));
  }
}

The factory itself is a one-time deploy. Every pair after that is a call into it — which is exactly why the recurring cost of those secondary deploys (Module 07) is what actually matters at volume.

CREATE2 & Deterministic Addresses

The chicken-and-egg wiring gets even cleaner if the contracts could be born already knowing each other's addresses. That's what CREATE2 gives you.

Normally a contract's address depends on the deployer's nonce, so you can't know it until you've deployed. With CREATE2, the address is a pure function of three inputs:

That dissolves the chicken-and-egg problem entirely. You compute the redeemer's future address, then deploy the ERC-721 and ERC-20 with that address already baked in as their authorized minter, then deploy the redeemer to exactly the address you predicted. No setters. No post-deploy wiring at all — the relationships are immutable from block one.

Two honest caveats

• Lay out the dependency graph deliberately. You can't have each contract circularly depend on the other's deployed form. The usual fix: the redeemer is the "hub" whose address you predict first; the tokens reference that predicted redeemer; the redeemer references the tokens (also predictable, since their salt + bytecode are known). Everything is computable up front — it just needs deliberate ordering.
• Salt management becomes your new bookkeeping. Deterministic addresses are only deterministic if you track which salt produced which set. Reusing a salt with the same bytecode collides — the second deploy just fails. Most factories derive the salt systematically: an incrementing counter, or a hash of the set's parameters — not something you hand-pick each time.

Minimal Proxy Clones (EIP-1167)

CREATE2 handles where. Clones handle how cheaply. If you're mass-producing sets, deploying three full contracts every time re-stores identical bytecode on-chain — the single most expensive thing you can do. EIP-1167 fixes that.

The one adjustment: clones can't use constructors. So the "baked-in addresses" move from constructor immutables to an initialize() call that the factory makes atomically right after cloning. Because it's all one transaction, the preconfigured property is preserved.

function createSet(bytes32 salt) external {
  address nft = Clones.cloneDeterministic(nftImpl, salt);     // CREATE2 clone
  address tok = Clones.cloneDeterministic(tokImpl, salt);
  address red = Clones.cloneDeterministic(redImpl, salt);
  IResultNFT(nft).initialize(red);      // wire, since no constructor
  IToken(tok).initialize(address(this));
  IRedeemer(red).initialize(tok, nft, cost);
}

The three compose cleanly: the factory removes manual overhead, CREATE2 removes the back-and-forth by making addresses knowable in advance, and clones make it cheap when you're doing it a lot.

What It All Costs

These are orders of magnitude, not quotes — real gas depends on your exact code, and live gas price + chain swamp everything. But the shape is what matters, and it's stark. Three tiers for the recurring, per-set cost:

The honest decision framing

Cost alone points at ERC-1155 — but cost was never the deciding factor. The ERC-721 question is. You pay the clone/factory premium specifically to get first-class ERC-721 result NFTs. If those NFTs must trade on standard marketplaces, be referenced by ERC-721-expecting contracts, or expose ownerOf/enumeration, that extra gas is the price of the property, and it's reasonable. If they don't, you're paying it for nothing and ERC-1155 wins on cost and simplicity.