NFT Ticketing on ERC721: Event Access and Anti Scalp Patterns

The ticketing industry runs on two failure modes. The first is counterfeiting. The second is uncapped resale: a wholesaler buys 500 tickets at $200, then sells them for $1,500 on a secondary marketplace and pockets the spread. Promoters and artists hate that. Fans hate it more.

ERC721 attacks both problems at the same time. Counterfeiting becomes impossible because the canonical owner record lives on chain. Uncapped resale becomes programmable because the contract decides which transfers are allowed. Neither property requires the user to understand a blockchain — the wallet sits inside a regular ticketing app.

The companion guide on creating an ERC721 NFT in Remix walks through the base contract. This post covers the additional surface a production ticketing contract ships on top.

// Minimal NFT ticket contract — ERC721 plus event metadata and a used flag
contract EventTicket is ERC721, AccessControl {
    bytes32 public constant VERIFIER_ROLE = keccak256("VERIFIER_ROLE");

    struct Event {
        uint64 eventStart;
        uint64 transferFreezeAt;   // block.timestamp after which transfers revert
        uint128 maxResalePriceWei; // 0 means no resale cap
        bool soulbound;            // true means tokens cannot transfer at all
    }

    mapping(uint256 => Event) public ticketEvent;     // tokenId => event
    mapping(uint256 => bool) public used;             // tokenId => redeemed flag
    mapping(uint256 => uint256) public lastResalePrice; // tokenId => last sale price

    constructor() ERC721("Event Ticket", "TKT") {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
    }

    function mint(
        address to,
        uint256 tokenId,
        Event calldata ev
    ) external onlyRole(DEFAULT_ADMIN_ROLE) {
        ticketEvent[tokenId] = ev;
        _safeMint(to, tokenId);
    }
}

The Event struct compresses the policy for each tokenId: when the event starts, when transfers freeze, whether resale is capped, whether the ticket is soulbound. Packing these into a single storage slot keeps mint cheap and the policy attached to the token itself rather than a separate config registry.

AccessControl gives us a clean way to express the verifier role: the wallets allowed to sign redemption messages at the door. In a production deployment those wallets live inside a hardware POS device at the venue entrance, separate from the deployer wallet that mints tickets.

// Anti scalp transfer hook — runs on every mint, transfer, and burn
function _beforeTokenTransfer(
    address from,
    address to,
    uint256 tokenId,
    uint256 batchSize
) internal override {
    super._beforeTokenTransfer(from, to, tokenId, batchSize);

    // Mint and burn are always allowed
    if (from == address(0) || to == address(0)) return;

    Event memory ev = ticketEvent[tokenId];

    // Soulbound tickets cannot transfer at all
    require(!ev.soulbound, "Ticket: soulbound");

    // Freeze transfers in the resale blackout window before the event
    require(block.timestamp < ev.transferFreezeAt, "Ticket: resale frozen");

    // Used tickets cannot be resold
    require(!used[tokenId], "Ticket: already redeemed");

    // Resale price cap — caller must declare price via setResalePrice first
    if (ev.maxResalePriceWei > 0) {
        require(
            lastResalePrice[tokenId] <= ev.maxResalePriceWei,
            "Ticket: above resale cap"
        );
    }
}

The freeze window is the most common pattern. The contract allows resale up to 48 hours before the event, then locks all transfers. The intent is to make wholesale resale impossible right when scalp demand peaks. Real holders who cannot attend at the last minute lose some flexibility; the contract owner sets the window to balance that against scalp prevention.

The resale price cap is the next most common pattern. The contract reads a declared price from the latest setResalePrice call and reverts if it exceeds the cap. This requires marketplace cooperation — the marketplace must call setResalePrice before the transfer. The contract cannot read the actual buyer payment otherwise.

Soulbound is the nuclear option. The transfer hook reverts on every non mint, non burn move. Each holder must show up themselves. Festivals and small venue tours use this. Stadium concerts almost never do because the resale flexibility is a feature for legitimate holders.

// Door scan flow — verifier signs an EIP-712 message, ticket is marked used
struct RedeemPayload {
    uint256 tokenId;
    address holder;
    uint256 nonce;
    uint64 deadline;
}

function redeem(RedeemPayload calldata p, bytes calldata sig) external {
    require(block.timestamp <= p.deadline, "Ticket: signature expired");
    require(ownerOf(p.tokenId) == p.holder, "Ticket: holder mismatch");
    require(!used[p.tokenId], "Ticket: already used");

    bytes32 digest = _hashTypedDataV4(
        keccak256(abi.encode(
            keccak256("RedeemPayload(uint256 tokenId,address holder,uint256 nonce,uint64 deadline)"),
            p.tokenId,
            p.holder,
            p.nonce,
            p.deadline
        ))
    );
    address signer = ECDSA.recover(digest, sig);
    require(hasRole(VERIFIER_ROLE, signer), "Ticket: bad verifier signature");

    used[p.tokenId] = true;
    emit Redeemed(p.tokenId, p.holder, signer);
}

The flow starts with the door device generating a one time EIP-712 payload tied to the tokenId, the current holder, a nonce, and a short deadline. The device signs the payload with its verifier key. The holder's ticketing app reads the signature, calls redeem on chain, and the contract verifies that the signature came from an authorized verifier wallet.

Two patterns reduce friction at the door. The first is sponsoring gas on the redeem transaction so the holder does not need ETH in their wallet to enter the venue. The second is using account abstraction (ERC-4337) so the holder signs a userOp inside the ticketing app and a paymaster covers the on chain cost.

Royalty enforcement on chain is contested. Some marketplaces respect ERC-2981. Others ignore it. The current direction of travel is to use OpenSea's operator filter or a custom transfer hook that only allows transfers through marketplaces that pay royalties. The pattern is becoming standard for production ticketing contracts that care about the resale revenue tail.

The combined effect: a single contract can capture primary sale revenue (mint), enforce resale rules on the secondary market (transfer hook), redeem at the venue (used flag), and earn royalties on every collectible trade after the event. That stack does not exist on a paper ticket.

Treat the chain as eventually consistent at the door. A redeem transaction takes a few seconds to confirm even on a fast L2. The door system should verify the verifier signature locally, admit the holder, and only commit the on chain redeem afterward. If the chain is congested, the holder is already inside and the contract catches up.

Use a layer 2 for the actual deployment. Base, Optimism, and Polygon all run with cents per redemption. Mainnet Ethereum at typical gas would price out every concert under $200 per ticket.

Keep an off chain mirror of redemption state for analytics and customer support. The chain is the source of truth, but you do not want every refund request to require an RPC roundtrip.

We help teams ship production grade NFT ticketing and access systems, including the contract, the door integration, the verifier key management, and the L2 deployment. A second deep dive on a related ERC721 use case lives at the real estate tokenization post — the contract patterns share more than they differ.